继承实现的设计问题答案

【问题标题】：Design Issues with Inheritance Implementation继承实现的设计问题
【发布时间】：2021-10-21 15:37:15
【问题描述】：

初始情况：- 我有 20 个不同的类，每个类都包含为每个下游系统提供源的代码，因此 20 个系统有 20 个类。不，我聘请了一位架构师来简化我的代码。

架构师建议应用 OOP 原则，我们应该使用继承并将通用功能移至基类，使用是与 20 个类的关系。

问题：- 这增加了我的可测试性工作，之前我们为每个下游都有单独的代码，因此只需要使用一个系统回归，但现在对于基类的任何更改，我们需要使用 20 个系统进行测试，因此应用 OOP 创建了更多问题。

应该如何设计来解决这个问题？

【问题讨论】：

有了这么多关于类、系统、代码、架构、技术、语言的信息，我们怎么不能超级超级有用？
顺便说一句，大多数时候从抽象类继承不是一个好主意，它很容易违反 SOLID 原则...如果您有通用代码，请创建一个 Service 类正是这样做的，这样您就可以测试与整个系统隔离的功能
我不确定我看到基类的使用如何突然改变了测试制度那。结构发生了变化，但您仍然有 20 个类（加上基类）。
'应该怎样设计才能解决这个问题？'为此，我们需要更多有关情况的信息，以及您想要实现的目标，而不是批评架构师说您应该做的事情。例如，什么是“提要”，是什么推动了对 20 个不同类别的需求等？

【解决方案1】：

简而言之，您可以尝试使用组合而不是继承。这可能会导致更稳定的下游特定对象，然后当常见事物发生变化时不需要对其进行测试。根据您的具体情况，这可能会或可能不会有帮助，但至少是一个明智的选择。

显然我们不知道您的具体情况。 一般来说继承确实有问题，应该尽可能避免。

更具体地说，从基类继承以共享代码（我假设这是您的情况，我不确定）也不是一个好习惯。所以打两个继承。

组合涉及为常见事物创建有用的抽象。基本上是一个独立的对象或做一些有用的事情的对象，但不是下游特定的。然后使用下游特定对象中的那些对象，而不是继承其中的任何一个。

【讨论】：