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!
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.