2

I am in the process of learning the MVC pattern in "practise", meaning that I am trying to get a grasp of how to implement it in any given Java application. I just got a little bit smarter through another question I just asked, and here comes my follow up.

Intrinsic to the MVC pattern is the fact that the model should not know of neither the view nor the controller. However, both the controller and the view must know of each other as the controller most likely needs to update the view, and the view needs to send user actions to the controller. I understand that one usually implements the controller using the strategy pattern, meaning that the controller is the behaviour of the view. Regardless of how one look at it, the view and controller are rather intertwined.

Now, I do know that one should favour composition over inheritance. However, would it make sense to create a design where the controller inherits the view. I am mostly thinking about not having to write a whole lot of accessor and mutator methods on the view, but rather define all components with the protected keywords so that subclasses can access them.

One might think how the view is supposed to be able to notify the controller when user input happens. My idea would be to have actions corresponding to each button in the controller. Then it would simply be a matter of registering the right action (in the controller, which is the subclass) with the corresponding button (in the view).

Am I about to blur out separation of concerns? Will this still be the MVC pattern, or am I heading towards something quite different (and worse)?

All feedback is most welcome!

Community
  • 1
  • 1
sbrattla
  • 5,274
  • 3
  • 39
  • 63
  • What's your objective? Are you trying to develop your own MVC framework? – CoolBeans Mar 08 '11 at 20:09
  • My objective is to understand how I can take advantage of the MVC pattern in my application. I do understand, from examples, that composition ideally is the way to go with regard to setting the controller as the "behaviour" of the view. However, it just struck me wether it would be just as simple to let any controller just extend the view. I admit it seems lazy, but i thought of it as a way to save time and code lines (isn't that what patterns is all about?). After all, the "behaviour" could easily be changed by just letting another inherit the view if that's desirable. – sbrattla Mar 09 '11 at 06:43

6 Answers6

4

When your controller extends the view, in the sense of Java, your controller "is-a" view. So it's quite safe to say that you are violating the mvc pattern in that case.

Jan Galinski
  • 11,768
  • 8
  • 54
  • 77
2

Don't listen to these fuddy duddys. Sounds like a great plan to me.

Here's the deal.

The fact that the Controller "is-a" View is a complete, total detail that's not important to the implementation. As long as nothing using the Controller is using it as a View, then who cares what the class hierarchy of the Controller is?

Now, by descending it from the View, then, in theory, the development environment can not "protect you" from "accidentally" using the Controller where a View is needed. That just puts the burden on you to be more careful.

Does it make your Controller any more dependent on the View than if it had a "has-a" relationship with it? Sorta. It DOES make it more difficult to "swap out" the View for a different, albeit similar View later on, but you could use that event as a motivation to do refactoring from a "is-a" relationship to "has-a".

Arguably, by doing this, you're just being "lazy", but I defer to Larry Wall about programmers and laziness.

From a modeling point of view, it's simply not that big of a deal, frankly save to pedants. Operationally it makes no difference.

Will Hartung
  • 115,893
  • 19
  • 128
  • 203
  • 1
    I am not a "fuddy duddy" ... that just needed to be said! – Jan Galinski Mar 08 '11 at 22:19
  • It's always great to hear two sides of the story! My idea was that the "behaviour" (controller) could just as easily be changed/switched by simply creating a second controller which extends the view. However, I do realize that one should "favour composition over inheritance"...but that does not mean inheritance should be ignored when it might actual come to good use. I'm a bit reluctant to use the word "lazy", but I certainly admin that I would like to write as few codes of line as possible to make it all work. – sbrattla Mar 09 '11 at 06:57
  • I used "lazy" and "fuddy duddy" in endearing ways :). – Will Hartung Mar 09 '11 at 16:51
  • I agree with this answer in theory... But I disagree with it in practice because of the fear that by inheriting the view, the coupling between the view and controller becomes even more tightly intwined. While yes, they are already tightly coupled, however, they should be conceptually as loosely coupled as possible so that it becomes easier to maintain. I *highly* suggest you take a look at Cocoa as an ideal example, and recommend that you find a way to generate the View non-programmatically if possible. Most modern toolkits allow the use of XML for this purpose. (moldnilo's answer is good!) – Arafangion Mar 10 '11 at 11:22
1

Don't go there - it will turn into an M-VCS (Model-ViewControllerSpaghetti) architecture.

In principle, I would say that user inputs (including buttons and other controls) don't belong to the view but to the controller (or to a GUI layer that has-a controller) while the view only displays the model.

It would be reasonable for your controller GUI to be familiar with the view and notify it that the model has been updated and that it should re-display the model. No accessors and mutators are necessary.

molbdnilo
  • 64,751
  • 3
  • 43
  • 82
  • Are you saying that the only method in need in the GUI is e.g. a stateChanged() method which the controller can trigger on the View when the View needs to update whatever it is displaying? I've just seen a lot of examples telling me to add methods for enabling/disabling fields, locking/unlocking fields to let the controller update state... – sbrattla Mar 09 '11 at 06:48
  • If my above comment is right, then that will in essence mean that the controller never can update the view directly, but only notify the view that it needs to update it's state. However, does the enabling/disabling or locking/unlocking "logic" of fields belong in the view or the controller? – sbrattla Mar 09 '11 at 06:50
  • It's also quite common to have the model notify both the controller and the view of changes (which is a better solution than having the controller fiddle with the view, actually). Regardless, it's very hard to be specific about such a general case. As with all kinds of patterns, MVC is not a ready-made, one-size-fits-all, magical silver hammer. You need to consider what exactly you want to achieve and then tailor your solution to your problem. Sorry if this is vague, but there's no "correct" answer (as you've noticed). – molbdnilo Mar 09 '11 at 13:46
  • @sbrattia: The best learning experience would be to implement several of the suggestions you've got and see which one works best for your problem. – molbdnilo Mar 09 '11 at 13:51
  • That's fair enought. I'll sit down and see if i can carve out a solution which works. Thanks for your comments though! – sbrattla Mar 09 '11 at 15:08
1

@Jan Galinski is correct. If you look at the example and picture cited in your previous question, you'll see that the Controller has-a View and it has-a Model, while the the View just has-a Model (solid arrows). The Controller listens-to the View, and the View listens-to the Model (dotted arrows).

Addendum: In this way, you can see the one-to-one correspondence between the class diagram and the code.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
1

Patterns are only patterns - You can play with them. (with additional care & comments for other developers).

Inheritance creates stronger encapsulation for the view element. That means the view can be managed only by its controller. That gives much more control over when and why the view is changed.

In the mentioned case, I recommend that view provides only protected constructors. And should not be managed or created outside the controller

If in any case the View is created without relation to the controller I do not recommend inheritance but composition.

Elendil
  • 11
  • 1
0

No i dont think its ok, for me this sounds really bad. it might be helpful in some situations but its sure not MVC anymore.