观察者模式遵循/违反了哪些 SOLID 原则？答案

【问题标题】：What SOLID principles does the observer pattern follow/violate?观察者模式遵循/违反了哪些 SOLID 原则？
【发布时间】：2018-11-13 21:49:20
【问题描述】：

我正在准备考试，目前正在阅读有关观察者模式的内容。然后我想知道观察者模式遵循或违反了哪些 SOLID 原则？

【问题讨论】：

【解决方案1】：

我自己的想法：

我认为它遵循 OCP，因为您将来可以使用新的观察者扩展代码，而不是修改现有代码以使这些新观察者适应。它也遵循 ISP，因为 Subject 和 Observer 接口对于观察者/主题要执行的特定工作来说既精确又小。

当我试图让其余的原则适合观察者模式时，它变得有点牵强。也许 ISP 也是如此？你都有些什么想法呢？软件设计模式不一定会利用所有原则，是吗？

【讨论】：

【解决方案2】：

设计模式——顾名思义——只是模式。它们的实际实现可能在各种应用程序中存在很大差异。

一般来说，与观察者最相关的 SOLID 原则是 Open/Close 原则：一旦你编写了被观察对象的代码，当你想让其他观察者知道时，你不需要更改代码，但它是很容易添加这样的观察者——这正是“对修改关闭，对扩展开放”的意思。

它也可以被认为是依赖倒置原则的应用：被观察的主体强制执行一个已知的 API，任何想要遵守它的人都必须遵循一些规则，特别是，被观察的主体将调用他们的 update() 函数调用观察者的特定函数。这样，如果要更改观察者，则被观察的类没有任何关系（与调用特定观察者函数的选项相比）。

在基本的经典实现（即来自 GoF 的实现）中，可能会违反 SRP 和 ISP。

在那个实现中，被改变的对象负责更新观察者。这是该类除了主要职责之外的另一项职责。因此，将来更新类的“原因”不止一个——如果必须更改更新机制（例如，使用不同的容器、使用线程安全机制等）——更改将发生在具有完全不同的主要职责的同一类。当然，这可以通过将“观察者”机制分离到另一个类来解决。

简单实现的另一个可能违反 SOLID 的情况是，根据 GoF 的该实现，每个更新的观察者随后应检查被观察对象的状态以检测更改。这可能意味着没有接口隔离，因为任何观察者都应该暴露于被观察对象中的所有内容。但是，它不必以这种方式工作，并且很容易为不同的观察者提供使用不同接口的更复杂的实现。

该模式与 Liskov 替换原则没有太大关系 - 只要继承（例如，通过具体类型继承观察者和被观察类型）不做他们不应该做的事情，就会保留该原则。

【讨论】：