Java 应用MVC模式时让控制器继承视图可以吗？

我正在“实践”中学习MVC模式，这意味着我试图掌握如何在任何给定的Java应用程序中实现它。我只是通过我刚才问的另一个问题变得更聪明了一点，下面是我的后续行动

MVC模式固有的一个事实是，模型既不应该知道视图，也不应该知道控制器。但是，控制器和视图必须相互了解，因为控制器最有可能需要更新视图，并且视图需要向控制器发送用户操作。我知道通常使用策略模式实现控制器，这意味着控制器就是视图的行为。无论人们如何看待它，视图和控制器都是交织在一起的

现在，我确实知道一个人应该倾向于组合而不是继承。但是，创建控制器继承视图的设计是否合理。我主要考虑的是不必在视图上编写大量的访问器和mutator方法，而是使用受保护的关键字定义所有组件，以便子类可以访问它们

有人可能会想，当用户输入发生时，视图应该如何通知控制器。我的想法是让动作对应于控制器中的每个按钮。然后，只需使用相应的按钮（在视图中）注册正确的操作（在控制器中，它是子类）

我是否即将模糊关注点的分离？这仍然是MVC模式吗，还是我正朝着完全不同（甚至更糟）的方向前进

---

欢迎所有反馈

当您的控制器扩展视图时，在Java的意义上，您的控制器是一个视图。因此，在这种情况下，可以很有把握地说您违反了mvc模式。

不，我认为这不好，对我来说，这听起来真的很糟糕。在某些情况下，它可能会有所帮助，但它肯定不再是MVC了。

不要去那里-它将变成一个M-VCS（Model ViewControllers Paghetti）体系结构

原则上，我会说用户输入（包括按钮和其他控件）不属于视图，而是属于控制器（或具有控制器的GUI层），而视图只显示模型

---

您的控制器GUI应该熟悉视图，并通知它模型已更新，并且应该重新显示模型。不需要访问器和变异器

詹·加林斯基是对的。如果您查看上一个问题中引用的和，您将看到

控制器

有-a

视图

和-a

模型

，而

视图

只有-a

模型

（实心箭头）。

控制器

监听

视图

，

视图

监听

模型

（虚线箭头）

---

附录：通过这种方式，您可以看到类图和代码之间的一一对应关系。

不要听这些陈词滥调。对我来说这是个很棒的计划

事情是这样的

事实上，控制器“是一个”视图是一个完整的、总体的细节，对于实现来说并不重要。只要没有使用控制器的东西将其用作视图，那么谁会关心控制器的类层次结构是什么呢

现在，通过从视图中删除它，那么，理论上，开发环境不能“保护”您，以免“意外地”在需要视图的地方使用控制器。那只会让你更加小心

它是否会使控制器比与视图有“has-a”关系时更依赖于视图？索塔。这确实会使以后“交换”视图以获得不同的（尽管是类似的）视图变得更加困难，但您可以将该事件作为从“is-a”关系到“has-a”关系进行重构的动机

可以说，这样做只是“懒惰”，但我遵从拉里·沃尔关于程序员和懒惰的说法

---

从建模的角度来看，这没什么大不了的，坦率地说，除了书呆子。从操作上来说，这没有什么区别。

你的目标是什么？您是否正在尝试开发自己的MVC框架？我的目标是了解如何在应用程序中利用MVC模式。从示例中，我确实了解到，在将控制器设置为视图的“行为”方面，组合是理想的方式。然而，我突然想到，让任何控制器仅仅扩展视图是否同样简单。我承认它看起来很懒惰，但我认为它是一种节省时间和代码行的方法（这难道不是模式的全部内容吗？）。毕竟，“行为”可以很容易地改变，只要让另一个人继承观点，如果这是可取的。我不是一个“老掉牙的达迪”。。。这就是我要说的！听到故事的两面总是很棒的！我的想法是，只要创建第二个扩展视图的控制器，“行为”（控制器）就可以很容易地改变/切换。然而，我确实意识到人们应该“偏爱组合而不是继承”……但这并不意味着继承在实际使用时应该被忽略。我有点不愿意用“懒惰”这个词，但我肯定我想写尽可能少的行代码来让它工作。我用了“懒惰”和“老掉牙的达迪”两个可爱的词：）。我在理论上同意这个答案。。。但实际上我不同意这种说法，因为我担心通过继承视图，视图和控制器之间的耦合会变得更加紧密。是的，它们已经紧密耦合，但是，它们应该在概念上尽可能松散耦合，以便更容易维护。我强烈建议您将Cocoa作为一个理想的例子，并建议您找到一种生成Vi的方法