我正在“练习”中学习 MVC 模式，这意味着我试图掌握如何在任何给定的 Java 应用程序中实现它。我刚刚通过我刚刚问的另一个问题变得更聪明了，这是我的跟进。
MVC 模式的本质是模型不应该知道视图和控制器。但是，控制器和视图都必须相互了解，因为控制器很可能需要更新视图，而视图需要将用户操作发送到控制器。据我了解，通常使用策略模式来实现控制器，这意味着控制器是视图的行为。不管怎么看，视图和控制器都是紧密相连的。
现在，我确实知道人们应该更喜欢组合而不是继承。但是，创建控制器继承视图的设计是否有意义。我主要考虑的是不必在视图上编写大量访问器和修改器方法，而是使用 protected 关键字定义所有组件，以便子类可以访问它们。
人们可能会想，当用户输入发生时，视图应该如何通知控制器。我的想法是让控制器中的每个按钮对应相应的操作。然后，只需用相应的按钮（在视图中）注册正确的操作（在控制器中，这是子类中）即可。
我是否会模糊关注点分离？这仍然是 MVC 模式，还是我正在走向完全不同（甚至更糟）的方向？
非常欢迎所有反馈！
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!
发布评论
评论（6）
当你的控制器扩展视图时，从 Java 的意义上来说，你的控制器“是一个”视图。因此，可以非常肯定地说，在这种情况下您违反了 mvc 模式。
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.
别听这些老古董的胡言乱语。对我来说听起来是一个很棒的计划。
事情是这样的。
事实上，控制器“是一个”视图是一个完整的、全面的细节，对于实现来说并不重要。只要没有任何使用Controller的东西将它用作View，那么谁关心Controller的类层次结构是什么？
现在，通过从视图下降，理论上，开发环境无法“保护您”免于“意外”使用需要视图的控制器。这只会增加你的负担，让你更加小心。
与控制器之间存在“has-a”关系相比，它是否会使您的控制器更加依赖于视图？有点。它确实使稍后将视图“交换”为不同但相似的视图变得更加困难，但您可以使用该事件作为从“is-a”关系重构为“has-a”的动机。
可以说，这样做只是“懒惰”，但我同意拉里·沃尔关于程序员和懒惰的看法。
从建模的角度来看，坦率地说，除了学究之外，这根本没什么大不了的。从操作上来说，这没有什么区别。
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.
不要去那里 - 它将变成 M-VCS (Model-ViewControllerSpaghetti) 架构。
原则上，我想说用户输入（包括按钮和其他控件）不属于视图，而是属于控制器（或有控制器的GUI层），而视图< em>仅显示模型。
您的控制器 GUI 应该熟悉视图并通知它模型已更新并且应该重新显示模型。不需要访问器和修改器。
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.
@Jan Galinski 是正确的。如果您查看示例和图片 在您上一个问题中引用，您会看到
Controllerhas-aView 和它 has-aModel，而View只是 has-aModel< /code>（实线箭头）。Controller监听View，View监听模型（虚线箭头）。附录：这样就可以看到类图和代码的一一对应关系。
@Jan Galinski is correct. If you look at the example and picture cited in your previous question, you'll see that the
Controllerhas-aViewand it has-aModel, while the theViewjust has-aModel(solid arrows). TheControllerlistens-to theView, and theViewlistens-to theModel(dotted arrows).Addendum: In this way, you can see the one-to-one correspondence between the class diagram and the code.
模式只是模式——你可以使用它们。 （对其他开发人员给予额外的关注和评论）。
继承为视图元素创建了更强的封装。这意味着视图只能由其控制器管理。这可以更好地控制视图更改的时间和原因。
在上述情况下，我建议视图仅提供受保护的构造函数。并且不应在控制器外部管理或创建
如果在任何情况下创建的视图与控制器无关，我不建议继承而是组合。
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.
不，我不认为这没关系，对我来说这听起来真的很糟糕。它在某些情况下可能会有所帮助，但它肯定不再是 MVC。
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.