【问题标题】：Identifying violations of the SOLID design principles识别违反 SOLID 设计原则的行为
【发布时间】：2022-10-06 18:55:55
【问题描述】：
我试图了解 SOLID 设计模式和设计原则。想象一下创建一个通知程序，其父类有一个称为发送通知的方法。现在，父类具有用于不同通知类型的子类，例如 SMS、Call 和电子邮件。创建程序后，我想通过允许它组合多个通知类型来扩展其功能，因此我创建了一个名为 SMS+Email 的子类来处理与 SMS 和电子邮件相关的通知我还创建了另一个子类来处理组合呼叫和电子邮件的通知电子邮件。
我知道这里一个好的设计策略是装饰器策略，而不是每次我想组合通知时都必须创建一个全新的子类，我可以创建一个包装类来做到这一点。
但是我在识别任何设计问题时遇到了问题。每个类都有一个特定的功能，因此当我想添加一个新功能时，它不能是一个单一的责任原则我可以轻松地创建一个子类，这样我就不会修改代码只是扩展它，所以我不会感觉违反了开闭原则。唯一想到的原则是依赖倒置原则和接口隔离原则，但我不太确定。
我觉得它违反了设计原则，因为它可以使用设计策略来实现，但我不太确定。
标签：
design-patterns
solid-principles
【解决方案1】：
不是每个问题都是违反 SOLID 的，在 SOLID 的范围内可能会做得非常糟糕。特别是，大部分软件设计都包括确定所有“单一职责”应该是什么。
记录每节课的目的并修正你不喜欢的那些。
当您已经拥有 SMS 类和 EMail 类时，为什么还要维护一个单独的“SMS+EMail”类？当你看到你应该害怕你必须为每个可能的组合创建一个类，并且选择组合配置而不是编码将是困难的。
对于您的特定问题，听起来更好的解决方案是创建一个CompositeNotifier 类。它将有一个其他通知者的列表，并将通知分发给所有通知者。这是一个可靠的解决方案：
- S：将通知分发到多个目标
- O：任何类型的目标通知器都可以在构造之后/期间添加到每个实例。
- L：它遵守它所实现的 Notifier 接口的约定
- 我：我认为您的父通知程序界面不包含任何不相关的内容
- D：它仅取决于目标的通知器抽象。注入特定类型的目标。 （依赖倒置通常是实现 Open/Closed 主体的方式）。
坚实的原则违规指标
- 单一责任原则：
组件是万事通。他们有多个不相关的职责。低内聚和高耦合。
- 开闭原则：
组件只能通过手术扩展。没有办法通过继承和多态扩展现有功能来添加功能。
- 里氏原理：
如果你用子类的对象替换超类的对象，软件就会崩溃。这是因为有些子类不是（IS A）超类。
- 接口隔离原理：
具有胖接口的组件。低内聚的接口。空方法在层次结构中无处不在。
- 依赖倒置原理：
你沿着层次结构走下去，突然发现一个孩子比它的父母更抽象。这是违规行为。抽象应该在层次结构中上推，细节应该下推。
许多违规行为在不同原则之间相互关联。请记住，可靠的 OOAD 设计创建了一个低维护、可扩展且高度通用的生态系统。很像孩子们的乐高积木。在乐高中，一切都是对高质量、耐用、可插拔项目的抽象。在层次结构中，您将看到方形立方体、矩形立方体、平底等，当您在层次结构中向下遍历时，您会看到更复杂的项目，如汽车、动物、树木等。