我正在为考试而学习，目前正在阅读有关观察者模式的信息。然后我想知道观察者模式遵循或违反哪些 SOLID 原则？
顾名思义，设计模式只是模式。它们的实际实现在各种应用程序之间可能有很大差异。
一般来说，与观察者最相关的 SOLID 原则是开/关原则：一旦你写了观察对象的代码，当你想让其他观察者知道它时，你不需要改变代码，但添加这样的观察者很容易 - 这正是"关闭修改，开放扩展"的意思。
它也可以被认为是依赖反转原则的应用：被观察主体强制执行一个已知的API，其中任何想要观察它的人都必须遵循一些规则，特别是，被观察主体将调用他们的update()函数，而不是调用观察者的特定函数。这样，如果要更改观察器，则观察类无关紧要(将其与调用特定观察器函数的选项进行比较(。
在基本的经典实现(即来自GoF的实现(中，可能存在违反SRP和ISP的行为。
在该实现中，正在更改的对象负责更新观察器。这是班级除了主要责任之外的另一项责任。因此，将来更新类的"原因"不止一个 - 如果必须更改更新机制(例如使用不同的容器，使用线程安全机制等( - 更改将发生在具有完全不同的主要责任的同一类上。当然，这可以通过将"观察者"机制分离到另一个类来解决。
简单实现的另一个可能的 SOLID 违规是，根据 GoF 的实现，每个更新的观察者都应该检查被观察对象的状态以检测变化。这可能意味着没有界面隔离，因为任何观察者都应该接触到被观察对象中的所有内容。但是，它不必以这种方式工作，并且很容易为不同的观察者提供更复杂的实现，这些实现使用不同的接口。
该模式与 Liskov 替换原则没有太大关系 - 只要继承(例如，通过具体类型继承观察者和观察类型(不做它们不应该做的事情，该原则就会被保留。
我自己的想法：
我认为它遵循 OCP，因为您将来可以使用新的观察器扩展代码，而不是修改现有代码以使这些新的观察者适应。 它还遵循 ISP，因为主体和观察者接口对于观察者/主体要执行的特定工作是精确且较小的。
当我试图使其余原则适合观察者模式时，这变得有点牵强。也许ISP也是？你有什么想法？ 软件设计模式不一定利用所有原则，是吗？