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