识别违反 SOLID 设计原则的行为
我试图理解 SOLID 设计模式和设计原则。想象一下创建一个通知程序，其父类具有一种称为发送通知的方法。现在，父类具有不同通知类型的子类，例如短信、呼叫和电子邮件。创建程序后，我想通过允许它组合多个通知类型来扩展其功能，因此我创建了一个名为 SMS+Email 的子类来处理与 SMS 和电子邮件相关的通知。我还创建了另一个子类来处理组合了呼叫和电子邮件的通知。电子邮件。
我知道这里一个好的设计策略是装饰器策略，而不是每次我想要组合通知时都必须创建一个全新的子类，我可以创建一个执行此操作的包装器类。
但我在识别任何设计问题时遇到了问题。每个类都有一个特定的功能，所以它不能是单一责任原则，当我想添加一个新功能时，我可以轻松地创建一个子类，这样我就不会修改代码，只是扩展它，所以我不觉得它是违反了开闭原则。我想到的唯一原则是依赖倒置原则和接口隔离原则，但我不太确定这些原则。
我觉得它违反了设计原则，因为它可以使用设计策略来实现，但我不太确定。
I'm trying to understand SOLID design patterns and design principles. Imagine creating a notification program, with a parent class that has one method called send notifications. Now the parent class has subclasses for different notification types like SMS, Call, and email. After creating the program I would like to extend its functionality by allowing it to combine more than one notification type so I create a subclass called SMS+Email to handle notifications relating to SMS and email I also create another subclass that handles notifications that combine call and email.
I know a good design strategy here would be a decorator strategy, instead of having to create a whole new subclass each time I want to combine the notification I could just create a wrapper class that does that.
But I'm a having problem identifying any design problem. Each class does a specific function so it can't be a single responsibility principle when I want to add a new function I could easily create a subclass that way I'm not modifying the code just extending it so I don't feel like it's violating the open-closed principle. The only principles that come to mind are the dependency inversion principle and the Interface Segregation Principle but I'm not too sure of those.
I feel like it violates a design principle since it could be implemented using a design strategy but I'm not so sure.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
并不是每个问题都是 SOLID 违规，而且在 SOLID 的范围内也有可能做得非常糟糕。特别是，软件设计的大部分内容包括确定所有“单一职责”应该是什么。
记录每个课程的目的并修复您不喜欢的课程。
当您已经有了 SMS 类和 EMail 类时，为什么还要维护一个单独的“SMS+EMail”类呢？当您看到这一点时，您应该担心必须为每种可能的组合创建一个类，并且通过配置而不是编码来选择组合将很困难。
对于您的特定问题，听起来更好的解决方案是创建一个 CompositeNotifier 类。它将有一个其他通知者的列表，并将通知分发给所有这些人。这是一个可靠的解决方案：
Not every problem is a SOLID violation, and it's possible to do a really bad job within SOLID's boundaries. In particular, much of software design consists of determining just what all the "single responsibilities" should be.
Document the purpose of each class and fix the ones the ones you don't like.
Why would you want to have a separate "SMS+EMail" class to maintain when you already have an SMS class and and EMail class? When you see that you should be afraid that you'll have to make a class for every possible combination, and that choosing combinations by configuration instead of coding will be difficult.
It sounds like a better solution for your particular problem is to create a
CompositeNotifierclass. It would have a list of other notifiers and would distribute notifications to all of them. This is a SOLID solution:坚实的原则违反指标
组件是所有行业的杰克。他们有多个无关的责任。低内聚力和高耦合。
组件只能通过手术扩展。无法通过通过继承和多态性扩展现有功能来添加功能。
如果您用子类的对象替换超类的对象，则SOFWare将会破裂。这是因为没有（A）超类的子类。
具有脂肪界面的组件。接口具有低内聚力。层次结构中无处不在。
高级模块取决于组件设计中的低级别模块，在类层次结构中，您会看到较低级别的类比更高级别的类更抽象。为了避免这种违规，您应该让高级和低级模块依赖于抽象（依赖关系反转），并且应通过对象工厂（依赖项注入）在不同的上下文中管理的模块（依赖性）（依赖性）控制）。
许多不同原则之间的违规行为是相关的。请记住，坚实的OOAD设计会产生低维护，可扩展和高度的Versetiale生态系统。几乎就像孩子们的乐高玩具。在Lego中，所有内容都是高质量，耐用，可插入物品（根接口）的抽象。在层次结构上，您会看到方形立方体，矩形立方体，平底基等，当您在层次结构中穿越时，您会看到更多复杂的物品，例如汽车，动物，树木等。
Solid principles violation indicators
Components are jack of all trades. They have multiple unrelated responsibilities. Low cohesion and high coupling.
Components are expandable only through surgery. There is no way to add functionality by extending existing functionalities through inheritance and polymorphism.
The sofware will break if you replace objects of superclass with objects of subclasses. This is because there are subclasses that are not (IS A) superclass.
Components with fat interfaces. Interfaces with low cohesion. Empty methods are everywhere in the hierarchy.
High level modules are dependent on low level modules in your component design and in class hierarchy you will see lower level classes being more abstract than the higher level classes. To avoid this violation, you should let both high and low level modules to be dependent on abstractions (Dependency Inversion) and dependenices should be passed to the modules via object factories (Dependency Injection) managed in a different context than the main flow (Inversion of Control).
Many of the violations are correlated between different principles. Remember a solid OOAD design creates a low-maintenance, extendable, and highly versetaile ecosystem. Pretty much like legos for kids. In lego everything is an abstraction of a high quality, durable, pluggable item (Root Interface). Up on the hierarchy you will see square cubes, rectangular cubes, flat bases, etc and as you traverse down in the hierarchy you will see more complex items like cars, animals, trees, etc.