Is this MVC?
I just finished reading Head First Design Patterns, which learned me a lot of stuff. But after reading the chapter about MVC I got a bit confused. I thought I was making my programs MVC (at least tried to) but now I am wondering. I take a small example.
I have a simple UI with a button and a textlabel. I have a simple model with one class, MakeRandomQuoteClass.java, it has one main method, changeQuote(), that at random pick a new quote and sets its instance variabel, currentQuote, to the picked quote. Then by using the observer pattern, the update method in the UI get to know about the change, calls the method getQuote from MakeRandomQuoteClass and displays the new quote.
So far I think I dont violate the MVC. But what I got unsure of when reading about it, is the controller part. When I press the button ("change quote"), the actionPerformed is called, and there I call model.changeQuote(). In the text the three parts was totally separated, but that might just have been the general description?
Message was edited by:
sandsater
[1073 byte] By [
sandsatera] at [2007-10-3 1:48:48]
Hi,
the general idea of design patterns or "model" patterns books is to get
you a feeling of how to cleanly seperate your code parts and find
responsibilites for each part to achieve better design and later on
scaling advantages with easier exchanging of code parts.
Regard your implementation of MVC. The book seperated the three parts for
certain reasion: decoupling (or loose coupling) brings you the advantage
of removing heavy dependencies between objects or whole program parts.
Try to think about why this could be important...
What you want to do is to decouple your model from the controller,
e.g. by using an Interface.
I hope you got a hint,
greetz,
Kai
Sometimes, you have to ignore patterns. As long as you don't have a bunch of controllers (i.e. listeners) that are reused regularly, there is no need for the controller layer.
Anonymous, inner classes are a convenient and fast way to implement listeners, but they work against the MVC pattern. Giving this up for the MVC pattern will only pay off when your project reached a certain size.
The seperation between view and logic is WAY more important, and is a must-have for even the smallest applications. Only experience will tell you, when it's time to work with 3-, 4-, or even more-tiered application models.
> So far I think I dont violate the MVC.
You don't "violate" a pattern. You decide if you need or not. You may not need it if it gives you a flexibility that you don't need.
A pattern is not a hard rule to follow. It may or may not be the best solution to a given problem, depending on the context.
> Sometimes, you have to ignore patterns. As long as
> you don't have a bunch of controllers (i.e.
> listeners) that are reused regularly, there is no
> need for the controller layer.
I disagree.
> Anonymous, inner classes are a convenient and fast
> way to implement listeners, but they work against the
> MVC pattern. Giving this up for the MVC pattern will
> only pay off when your project reached a certain
> size.
Another way to accomplish this is to inject the listeners into the UI. The listeners are part of the controller. The UI knows it needs listeners, but it doesn't need to know what they do. Have the controller instantiate the UI, create the listeners and inject them into the UI. Nice and clean.
%
>
> The seperation between view and logic is WAY more
> important, and is a must-have for even the smallest
> applications. Only experience will tell you, when
> it's time to work with 3-, 4-, or even more-tiered
> application models.
