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

【问题标题】：Is it OK to let the controller inherit the view when applying the MVC pattern?应用MVC模式时让控制器继承视图可以吗？
【发布时间】：2011-07-11 09:30:22
【问题描述】：

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

MVC 模式的内在特点是模型不应该知道视图和控制器。但是，控制器和视图都必须相互了解，因为控制器很可能需要更新视图，并且视图需要将用户操作发送给控制器。我知道通常使用策略模式来实现控制器，这意味着控制器是视图的行为。不管怎么看，view 和 controller 都是交织在一起的。

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

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

我是否要模糊关注点分离？这仍然是 MVC 模式，还是我正在走向完全不同（甚至更糟）的东西？

欢迎所有反馈！

【问题讨论】：

你的目标是什么？您是否正在尝试开发自己的 MVC 框架？
我的目标是了解如何在我的应用程序中利用 MVC 模式。我确实从示例中了解到，理想情况下，组合是将控制器设置为视图的“行为”的方法。然而，让任何控制器扩展视图同样简单，这让我感到震惊。我承认它看起来很懒惰，但我认为它是一种节省时间和代码行的方法（这不就是模式的全部意义吗？）。毕竟，如果需要的话，只要让另一个人继承视图，就可以很容易地改变“行为”。

标签： java model-view-controller swing

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

不要去那里 - 它会变成一个 M-VCS (Model-ViewControllerSpaghetti) 架构。

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

控制器 GUI 熟悉视图并通知它模型已更新并且它应该重新显示模型是合理的。不需要访问器和修改器。

【讨论】：

你是说 GUI 中唯一需要的方法是例如当视图需要更新它显示的任何内容时，控制器可以在视图上触发的 stateChanged() 方法？我刚刚看到很多例子告诉我添加启用/禁用字段的方法，锁定/解锁字段以让控制器更新状态...
如果我上面的评论是正确的，那么这本质上意味着控制器永远不能直接更新视图，而只会通知视图它需要更新它的状态。但是，字段的启用/禁用或锁定/解锁“逻辑”是否属于视图或控制器？
让模型通知控制器和视图更改也很常见（实际上，这比让控制器摆弄视图更好）。无论如何，很难具体说明这种一般情况。与各种图案一样，MVC 也不是现成的、一刀切的、神奇的银锤。您需要考虑您究竟想要实现什么，然后针对您的问题定制解决方案。抱歉，如果这含糊不清，但没有“正确”的答案（正如您所注意到的）。
@sbrattia：最好的学习体验是实施你的一些建议，看看哪一个最适合你的问题。
这很公平。我会坐下来看看我是否能找到一个可行的解决方案。不过感谢您的 cmets！

【解决方案4】：

@Jan Galinski 是正确的。如果您查看上一个问题中引用的example 和picture，您会看到Controller has-a View 和它has-a em> Model，而 View 只是 has-a Model（实线箭头）。 Controller listens-to View，View listens-to Model（虚线箭头）。

附录：这样可以看到类图和代码一一对应。

【讨论】：

【解决方案5】：

不要听这些老一套的。对我来说，这听起来像是一个很棒的计划。

这是交易。

事实上，控制器“是一个”视图是一个完整的、完整的细节，对实现并不重要。只要不使用Controller就是把它当作View，那么谁在乎Controller的类层次是什么？

现在，通过将其从 View 降级，理论上，开发环境无法“保护您”免受“意外”使用需要 View 的 Controller 的影响。这只会让你有责任更加小心。

它是否使你的控制器更依赖于视图而不是它与它有“has-a”关系？排序。它确实使稍后将视图“交换”为不同的，尽管相似的视图变得更加困难，但是您可以使用该事件作为将“is-a”关系重构为“has-a”的动力。

可以说，这样做只是“懒惰”，但我听从 Larry Wall 关于程序员和懒惰的看法。

从建模的角度来看，这根本不是什么大不了的事，坦率地说，除了学究。在操作上没有区别。

【讨论】：

我不是一个“笨蛋”……这只是需要说的！
听到故事的两个方面总是很棒！我的想法是“行为”（控制器）可以通过简单地创建扩展视图的第二个控制器来轻松更改/切换。但是，我确实意识到应该“优先组合而不是继承”......但这并不意味着当它可能真正有用时应该忽略继承。我有点不情愿使用“懒惰”这个词，但我当然希望尽可能少地编写行代码以使其正常工作。
我以讨人喜欢的方式使用了“懒惰”和“fuddy duddy”:)。
理论上我同意这个答案...但实际上我不同意，因为担心通过继承视图，视图和控制器之间的耦合变得更加紧密。虽然是的，但它们已经紧密耦合，但是，它们在概念上应该尽可能松散耦合，以便更容易维护。我高度建议您将 Cocoa 视为一个理想的示例，并建议您尽可能找到一种以非编程方式生成 View 的方法。大多数现代工具包都允许为此目的使用 XML。（moldnilo 的回答很好！）