RareScrap Asked:2020-08-03 07:36:43 +0000 UTC2020-08-03 07:36:43 +0000 UTC 2020-08-03 07:36:43 +0000 UTC 什么时候不应该使用 SOLID？ 772 我读到 SOLID 是很好的建议，经过时间考验，但你不应该将它们强加到每个项目中。在没有必要使用它并且没有找到它的情况下搜索示例。告诉我，在什么情况下使用 SOLID 是不合理的？ ооп 2 个回答 Voted Best Answer Vladimir Gamalyan 2020-08-04T14:19:44Z2020-08-04T14:19:44Z 对于任何开发模式/原则，我们可以说： 如果您遵循它，则无法保证您的代码会自动变得更加正确、可扩展和可维护。 如果您不遵循它，则无法保证您的代码会自动变得有问题、不可扩展和不可维护。 按照它，您可以解决代码中的一个问题（或不解决它），但会产生新的问题。 对所使用的原则/模式也存在不完整甚至不正确的理解。当对它们的字面遵守变得超出常识时，甚至有可能被提升为绝对。 因此，问题不是什么时候不使用 SOLID，而是在您的特定情况下使用它的每个原则的程度。 S - 单一职责原则 一个类应该只有一个职责 由于职责分离不充分，我们得到了“上帝”反模式，班级变成了食品加工机。同时，过多的分离会导致代码碎片化，以至于每个类中几乎只有一行代码组成一个方法。因此，感知的复杂性可能会增加。 O - 开闭原则 软件实体必须对扩展开放，对修改关闭。 假设一个基类包含共同的实现细节，并且几个后代对其进行了改进。遵循这一原则，在添加新后代时，必须将它们的共同特征移到一个中间类中，以免触及基类。随着时间的推移，可能会形成一个奇怪的层次结构，尽管可能值得考虑修改基类的选项（尽管可能会破坏已经存在的后代）。 L - 里氏替换原则 程序中的对象必须可以用其子类型的实例替换，而不会改变程序的正确执行。 为了确保这一原则，有时有必要使用可疑的解决方案。例如，一个类Ellipse有一个子类，该子类Circle是Ellipse沿轴X和具有相同长度的情况Y。原则上，子类Circle必须实现父类的行为。如果Ellipse它包含stretchX允许您修改沿 axis 的长度的方法X，则该类Cirlce也必须实现此行为，即使这对于圆是不可能的。 一、接口隔离原则 许多客户特定接口优于一个通用接口 要求客户端不依赖于它们不使用的接口。在实践中，尤其是考虑不周的架构，这可能会导致碎片化为一个或两个方法的非常小的接口，以满足许多客户。 D - 依赖倒置原则 依赖倒置原则 让我们考虑一个类对象A调用类对象的方法的情况B。所以这A取决于B。应用此原则后，类型对象B必须在外部实例化A并作为依赖项传递给A. 不应用这个原则，对象本身就可以做到这一点A，这在很多情况下要方便得多。 基于http://www.tonymarston.net/php-mysql/not-so-solid-oo-principles.html。我在读书时学到了很多东西。欢迎霍利瓦） Sergey Teplyakov 2020-08-21T02:01:16Z2020-08-21T02:01:16Z 与任何工具一样，需要明智地应用设计原则。 有两种情况，设计原则的应用会导致更多的问题，没有好处。 亚格尼 详细信息在问题“ OCP 和 DIP（来自 SOLID）是否违反 YAGNI 原则？ ”的答案中。”。 设计原则旨在减轻特定的设计问题（是的，“减轻”，但不是解决问题），同时增加它们自己的问题。 由于程序员有时会为自己制造问题，因此遵循（尤其是字面上的）设计原则会使设计出现偏差，而不会解决真正的问题。 换句话说，过度放纵设计原则会导致不需要复杂性的解决方案过于复杂。 “超过”-SOLID 文章“关于设计原则”中有更多详细信息。 SOLID 原则有许多典型的病态用例： Anti-SRP - 责任模糊原则。类被分解成许多更小的类，导致逻辑分布在多个类/模块中。 反 OCP – 工厂原则的工厂。设计过于笼统和可扩展，太多的抽象层次突出。 反LCP——不可理解的继承原理。这个原则要么表现为过多的继承，要么完全没有，这取决于当地首席架构师的经验和观点。 反ISP——千接口原理。类接口被分成太多块，不方便所有客户端使用。 Anti-DIP - 意识反转或 DI 脑的原理。接口分配给每个类，并通过构造函数批量传递。几乎不可能理解逻辑在哪里。
对于任何开发模式/原则，我们可以说：
对所使用的原则/模式也存在不完整甚至不正确的理解。当对它们的字面遵守变得超出常识时，甚至有可能被提升为绝对。
因此，问题不是什么时候不使用 SOLID，而是在您的特定情况下使用它的每个原则的程度。
S - 单一职责原则
一个类应该只有一个职责
由于职责分离不充分，我们得到了“上帝”反模式，班级变成了食品加工机。同时，过多的分离会导致代码碎片化，以至于每个类中几乎只有一行代码组成一个方法。因此，感知的复杂性可能会增加。
O - 开闭原则
软件实体必须对扩展开放，对修改关闭。
假设一个基类包含共同的实现细节，并且几个后代对其进行了改进。遵循这一原则，在添加新后代时，必须将它们的共同特征移到一个中间类中，以免触及基类。随着时间的推移，可能会形成一个奇怪的层次结构，尽管可能值得考虑修改基类的选项（尽管可能会破坏已经存在的后代）。
L - 里氏替换原则
程序中的对象必须可以用其子类型的实例替换，而不会改变程序的正确执行。
为了确保这一原则，有时有必要使用可疑的解决方案。例如，一个类
Ellipse有一个子类，该子类Circle是Ellipse沿轴X和具有相同长度的情况Y。原则上，子类Circle必须实现父类的行为。如果Ellipse它包含stretchX允许您修改沿 axis 的长度的方法X，则该类Cirlce也必须实现此行为，即使这对于圆是不可能的。一、接口隔离原则
许多客户特定接口优于一个通用接口
要求客户端不依赖于它们不使用的接口。在实践中，尤其是考虑不周的架构，这可能会导致碎片化为一个或两个方法的非常小的接口，以满足许多客户。
D - 依赖倒置原则
依赖倒置原则
让我们考虑一个类对象
A调用类对象的方法的情况B。所以这A取决于B。应用此原则后，类型对象B必须在外部实例化A并作为依赖项传递给A. 不应用这个原则，对象本身就可以做到这一点A，这在很多情况下要方便得多。基于http://www.tonymarston.net/php-mysql/not-so-solid-oo-principles.html。我在读书时学到了很多东西。欢迎霍利瓦）
与任何工具一样，需要明智地应用设计原则。
有两种情况，设计原则的应用会导致更多的问题，没有好处。
亚格尼
详细信息在问题“ OCP 和 DIP（来自 SOLID）是否违反 YAGNI 原则？ ”的答案中。”。
设计原则旨在减轻特定的设计问题（是的，“减轻”，但不是解决问题），同时增加它们自己的问题。
由于程序员有时会为自己制造问题，因此遵循（尤其是字面上的）设计原则会使设计出现偏差，而不会解决真正的问题。
换句话说，过度放纵设计原则会导致不需要复杂性的解决方案过于复杂。
“超过”-SOLID
文章“关于设计原则”中有更多详细信息。
SOLID 原则有许多典型的病态用例：
Anti-SRP - 责任模糊原则。类被分解成许多更小的类，导致逻辑分布在多个类/模块中。
反 OCP – 工厂原则的工厂。设计过于笼统和可扩展，太多的抽象层次突出。
反LCP——不可理解的继承原理。这个原则要么表现为过多的继承，要么完全没有，这取决于当地首席架构师的经验和观点。
反ISP——千接口原理。类接口被分成太多块，不方便所有客户端使用。
Anti-DIP - 意识反转或 DI 脑的原理。接口分配给每个类，并通过构造函数批量传递。几乎不可能理解逻辑在哪里。