我正在“练习”中学习MVC模式，这意味着我正在努力掌握如何在任何给定的Java应用程序中实现它。通过我刚刚问的另一个question，我刚刚变得更聪明了一点，下面是我的后续内容。
MVC模式的本质是模型既不应该知道视图也不应该知道控制器。然而，控制器和视图都必须知道对方，因为控制器很可能需要更新视图，而视图需要向控制器发送用户操作。我理解人们通常使用策略模式来实现控制器，这意味着控制器是视图的行为。不管人们如何看待它，视图和控制器是相当交织在一起的。
现在，我知道了一个人应该更喜欢组合而不是继承。然而，创建一个控制器继承视图的设计是否有意义呢？我主要考虑的是不必在视图上编写大量的访问器和变异器方法，而是用protected关键字定义所有组件，以便子类可以访问它们。
有人可能会想，视图应该如何能够在用户输入发生时通知控制器，我的想法是让操作与控制器中的每个按钮相对应，然后只需将正确的操作（在控制器中，它是子类）注册到相应的按钮（在视图中）即可。
我是否要模糊关注点的分离？这仍然是MVC模式吗？或者我正朝着完全不同（甚至更糟）的方向前进？
欢迎所有反馈！
6条答案
按热度按时间i7uq4tfw1#
当你的控制器扩展视图时，在Java的意义上，你的控制器是一个视图，所以可以很肯定地说，在这种情况下你违反了mvc模式。
gev0vcfq2#
别听这些老古董的，我觉得这是个好主意。
是这样的
事实上，控制器是一个完整的视图，对于实现来说并不重要。只要没有任何东西使用控制器作为视图，那么谁在乎控制器的类层次结构是什么？
现在，通过将其从视图中降下来，那么，理论上，开发环境不能"保护"您在需要视图的地方"意外地"使用控制器，这只会让您更加小心。
这是否会使你的控制器比它与视图有"有"关系时更依赖于视图呢？算是吧。它确实会让你更难"换出"视图，换成一个不同的，尽管是类似的视图，但你可以利用这个事件作为一个动机，从"有"关系重构为"有"关系。
可以说，这样做只是"懒惰"，但我听从LarryWall关于程序员和懒惰的观点。
从建模的Angular 来看，这根本不是什么大问题，坦率地说，除了学究。操作上没有什么区别。
irlmq6kh3#
不要去那里-它会变成一个M-VCS（模型视图控制器意大利面）架构。
原则上，我会说用户输入（包括按钮和其他控件）不属于视图，而是属于控制器（或 * 具有 * 控制器的GUI层），而视图 * 仅 * 显示模型。
你的控制器GUI应该熟悉视图，并通知它模型已经更新，应该重新显示模型，不需要访问器和赋值器。
mccptt674#
@Jan Galinski是正确的，如果你看一下你上一个问题中引用的example和picture，你会发现
Controller* 有-a *View，它 * 有-a *Model，而View只有 * 有-a *Model``Controller* 侦听 *View，View* 侦听 *Model（虚线箭头）。补遗：通过这种方式，您可以看到类图和代码之间的一一对应关系。
yx2lnoni5#
不，我不认为这是好的，对我来说，这听起来真的很糟糕。它可能是有帮助的，在某些情况下，但它肯定不是MVC了。
vjhs03f76#
模式仅仅是模式--你可以玩弄它们。（对其他开发人员要格外小心和评论）。
继承为视图元素创建了更强大的封装，这意味着视图只能由其控制器管理，这就给了视图何时以及为何被更改提供了更多的控制。
在上面提到的情况下，我建议视图只提供受保护的构造函数，并且不应该在控制器之外管理或创建
如果在任何情况下创建的视图与控制器没有关系，我不推荐继承，而是组合。