关闭。这个问题是opinion-based .它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.
8年前关闭。
Improve this question
OOD(面向对象设计)和 MVC(模型- View - Controller )架构已成为现代软件设计的主要内容。然而，我最近对 MVC 架构如何利用(甚至可能违反)OOD 原则进行了有趣的讨论。这种可能性实际上相当有趣，因为 OOD 和 MVC 都旨在实现许多相同的目标:关注点分离和软件可重用性。但我提出的问题:这两种设计策略是否相互直接冲突？ 由于我在实践中使用过两者，因此我开始思考:很可能是。
我这么说是因为:在模型、 View 和 Controller 之间强制严格分离通常会导致模型被实现为只能通过外部 Controller 操作的哑容器的架构。我认为这直接与面向对象设计的主要原则之一相冲突:对象包含执行必要操作并根据需要封装它们的操作。例如，在纯面向对象架构中，假设 File类将包含诸如 open() 之类的方法和 save() . MVC 建议我们有两个类 File和 FileManager (例如后者包含 open() 和 save() 方法)。对我来说:MVC 设计相当困惑。如果需要创建更专业的类型 File (比如处理在 open() 或 save() 上通过网络传输的文件)，只需要子类 File有一个名为(假设)的类:StreamedFile .使用 MVC，您要么创建另一个管理器类，要么使原始管理器类的设计复杂化。
由此，因此，在更复杂的系统中，MVC 可能会对关注点分离和代码可重用性产生灾难性的影响。或不？也许可以在不破坏 OOD 原则的情况下实现 MVC 模式？还是 MVC 是一种固有缺陷的方法，它使得难以实现具有松散耦合组件的软件系统？
最佳答案
相反，健康的 MVC 使用应该鼓励瘦 Controller 和胖模型，以便模型(对象)是 Action 发生的地方(这本身鼓励封装和其他良好的 OOP 原则)，而 Controller 只是为了指向某些请求在正确的方向上的对象。
关于oop - 模型- View - Controller 是糟糕的面向对象设计吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5782842/