我正在使用 MVP 模式来开发大型应用程序。在开发过程中，我提出了是否应该使用组合或继承的问题。例如:假设我有一个名为 的表单。富带字段 一个 和 乙 .在应用程序的其他部分，我有一个表格 酒吧 具有相同字段 一个 和 乙 但额外的字段 C .
目前，代码是用继承方式编写的，其中 View 形式酒吧 继承自表单 富 .然后演示者处理与模型略有不同的数据。这很简单，但是否遵循“是 A”的经验法则让我感到震惊，因为即使表单不同，它们也会处理常见的输入(A 和 B)。
但是，在这里我一直在考虑“组合优于继承”和 Liskov Substitution Principle并开始认为我应该使用组合而不是继承。但是，由于我使用的是 MVP，它比预期的要复杂，因为我必须为表单 设置演示者。富带字段 一个 和 乙 然后是 的主持人酒吧 带字段 C 以及对 的演示者的引用富以便它可以注入(inject)字段 一个 和 乙 进去。
问题是它已被证明是更多的代码，因为我将不得不在 的演示者中添加一些排序的 getter 和 setter。富以便能够将数据传递给 酒吧 .这感觉就像我打破 MVP 以提供组合。
所以我的问题是:
在我的情况下，使用组合而不是继承真的更好吗？为什么？
使用组合“打破”MVP 吗？
最佳答案
Is it really better for my case to use composition over inheritance? Why?
是的。因为组合在更大的应用程序中更可靠、更安全、更易于维护、更易于发现、更易于记录和更易于理解。恕我直言。 :)
Does using composition "break" MVP?
是的。它打破了你现在正在做的那种简单的 MVP。组合让您可以选择如何耦合您的代码，这对于较大的应用程序非常有用。它确实使用了更多代码，因为您必须具体了解如何耦合。
一个简单的应用程序增长，并成为从简单的 MVP 继承过渡到更复杂的组合的一个很好的候选者是非常合理的。这是一个解耦步骤，可以以新的方式重新耦合。
这类似于有多少简单的 Web 应用程序正在转变为前端/后端 API 驱动的应用程序。这本质上是将前端用户 View 与后端存储模型解耦。
关于design-patterns - MVP 中的组合与继承，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14544504/