观察者模式常见于事件处理系统、gui框架、消息队列和mvc架构。例如，gui中的按钮点击作为主题，监听函数作为观察者；股票交易系统中，股票价格变动为主题，投资者为观察者。应用场景包括：1. 事件驱动系统；2. 用户界面组件通信；3. 消息传递机制；4. 数据模型与视图同步更新。避免循环依赖可通过弱引用、引入中间层、限制通知范围、事件过滤等方式实现。区别方面，观察者模式主题直接通知观察者，耦合度较高；而发布/订阅模式通过消息代理通信，解耦更彻底，适用于异步复杂场景。两种模式的选择取决于对耦合度和灵活性的需求。
Python中实现观察者模式，核心在于定义一个主题（Subject）类，维护一个观察者（Observer）列表，并在主题状态改变时通知所有观察者。解耦的关键在于，主题和观察者之间通过抽象接口进行交互，而不是具体实现，从而降低它们之间的依赖性。
解决方案
观察者模式是一种行为设计模式，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象的状态发生改变时，会通知所有观察者对象，使它们能够自动更新。
在Python中，可以通过以下步骤实现观察者模式：
立即学习“Python免费学习笔记（深入）”；
-
定义观察者接口 (Observer)：定义一个包含
update方法的抽象类或接口。所有具体的观察者类都必须实现这个接口。
定义具体观察者类 (ConcreteObserver)：实现观察者接口，并在
update方法中定义接收到主题通知后要执行的操作。定义主题接口 (Subject)：定义一个包含添加、删除和通知观察者方法的抽象类或接口。
定义具体主题类 (ConcreteSubject)：实现主题接口，维护一个观察者列表，并在状态改变时遍历列表，调用每个观察者的
update方法。客户端代码：创建主题对象和观察者对象，并将观察者对象注册到主题对象中。当主题对象的状态发生改变时，客户端代码不需要直接操作观察者对象，而是由主题对象自动通知所有观察者对象。
from abc import ABC, abstractmethod
# 观察者接口
class Observer(ABC):
@abstractmethod
def update(self, subject):
pass
# 具体观察者
class ConcreteObserverA(Observer):
def update(self, subject):
print(f"ConcreteObserverA: Subject's state is {subject.state}")
class ConcreteObserverB(Observer):
def update(self, subject):
print(f"ConcreteObserverB: Subject's state is {subject.state}")
# 主题接口
class Subject(ABC):
@abstractmethod
def attach(self, observer):
pass
@abstractmethod
def detach(self, observer):
pass
@abstractmethod
def notify(self):
pass
# 具体主题
class ConcreteSubject(Subject):
def __init__(self):
self._observers = []
self._state = None # 初始状态设为None
def attach(self, observer):
self._observers.append(observer)
def detach(self, observer):
self._observers.remove(observer)
def notify(self):
for observer in self._observers:
observer.update(self)
@property
def state(self):
return self._state
@state.setter
def state(self, state):
self._state = state
self.notify()
# 客户端代码
if __name__ == "__main__":
subject = ConcreteSubject()
observer_a = ConcreteObserverA()
subject.attach(observer_a)
observer_b = ConcreteObserverB()
subject.attach(observer_b)
subject.state = "State 1"
subject.state = "State 2"
subject.detach(observer_a)
subject.state = "State 3"观察者模式有哪些常见的应用场景？
观察者模式在事件处理系统、GUI 框架、消息队列、模型-视图-控制器（MVC）架构等场景中非常常见。例如，在GUI框架中，按钮点击事件可以被视为主题，而监听按钮点击事件的函数或对象可以被视为观察者。当按钮被点击时，主题（按钮）会通知所有注册的观察者（监听函数或对象），从而触发相应的操作。再比如，在股票交易系统中，股票价格的变动可以被视为主题，而关注该股票的投资者可以被视为观察者。当股票价格发生变动时，系统会通知所有关注该股票的投资者，以便他们及时做出决策。
如何避免观察者模式中的循环依赖？
循环依赖是指观察者和主题之间相互依赖，导致系统陷入无限循环。例如，观察者A监听主题B，而主题B又监听观察者A。当主题B发生改变时，会通知观察者A，而观察者A在接收到通知后又会改变主题B的状态，从而导致主题B再次通知观察者A，形成循环。
避免循环依赖的方法包括：
- 使用弱引用：使用弱引用可以防止观察者对象阻止主题对象被垃圾回收。
- 引入中间层：引入一个中间层来协调观察者和主题之间的交互。
- 限制通知范围：只通知必要的观察者，避免不必要的通知。
- 事件过滤：观察者只处理特定类型的事件，忽略其他事件。
观察者模式与发布/订阅模式有什么区别？
虽然观察者模式和发布/订阅模式都用于实现一对多的依赖关系，但它们之间存在一些关键区别。
- 中介者：观察者模式中，主题直接维护观察者列表并通知它们。而在发布/订阅模式中，发布者和订阅者之间通过一个消息代理（Message Broker）进行通信。发布者将消息发布到消息代理，而订阅者从消息代理订阅消息。
- 耦合度：观察者模式中，主题需要知道所有观察者的具体类型。而在发布/订阅模式中，发布者和订阅者之间是解耦的，发布者不需要知道任何订阅者的信息。
- 灵活性：发布/订阅模式比观察者模式更灵活，因为它允许发布者和订阅者在不同的时间点进行交互，并且支持更复杂的订阅规则。
选择使用哪种模式取决于具体的应用场景。如果需要实现简单的、同步的一对多依赖关系，并且主题和观察者之间的耦合度可以接受，那么观察者模式是一个不错的选择。如果需要实现更复杂的、异步的、解耦的一对多依赖关系，那么发布/订阅模式可能更适合。
