什么时候应该和不应该扩展一个类，它对 MVC 有效吗？答案

【问题标题】：When should and shouldn't I extend a class, and is it valid for MVC?什么时候应该和不应该扩展一个类，它对 MVC 有效吗？
【发布时间】：2011-05-25 21:20:59
【问题描述】：

我正在考虑使用类扩展来连接我的模型和控制器。我尝试在互联网上查找，但找不到有关此主题的任何信息。这让我想到了什么时候应该扩展课程以及出于什么原因的问题。

这是我的计划：

原因： 我可以将视图不应触及或更改的所有方法和变量设置为受保护的（即受保护的 var myVar:String）。这使我能够确保视图仍然可以访问它需要的数据，但无法进行意外更改。

整个思考过程源于这样一个事实，即我不希望我的视图有任何影响，同时仍然保持独立（即我可以拥有同一模型的多个视图，而无需告诉控制器另一个视图已添加）。

总结一下：

感谢您阅读到最后。

【问题讨论】：

【解决方案1】：

控制器不应该扩展模型——它们在 MVC 三元组中做了两个不同的事情，因此应该是两个不同的类。扩展 Model 类的正当理由是为其添加额外的功能，例如 BigModel

这里是MVC结构各部分的总结

【讨论】：

嗯，我明白了，所以扩展一个类意味着它会做同样的事情（甚至更多）。由于模型和控制器做不同的事情，扩展是没有意义的。但是，除了这是惯例之外，我看不到功能上的差异。在创建时扩展模型或将模型类赋予控制器类似乎做同样的事情。而且我看到了使用扩展模型的优势，因为它允许使用受保护的方法。

【解决方案2】：

您的视图将无法访问模型/控制器的受保护方法。受保护并不意味着只读，它意味着只有扩展基类的类才能访问受保护的属性或方法。

要在模型中设置只读属性，您应该考虑使用私有/受保护属性，然后为每个属性创建一个公共 getter 函数（然后可以读取属性但不能设置属性）。

还可以从视图访问模型，考虑将模型创建为单例，以便可以从应用程序中的任何位置访问它。

控制器除了监听和发送事件/通知之外通常不会做太多其他事情，有时对于小型项目，您可以让您的模型类（单例）扩展 EventDispatcher 并让它几乎做任何您想做的事情，但这不是纯 MVC，如果项目范围扩大，很快就会导致技术债务。

【讨论】：

我很喜欢你的回答。我大多同意。但是，它没有解决的一个问题是我希望我的控制器更改模型中的值，但我不希望我的视图具有相同类型的访问权限。也许我误解了 MVC，因为控制器首先不应该能够更改模型中的值？你对此有什么想法吗？