本系列文章是希望将软件项目中最常见的设计模式用通俗易懂的语言来讲解清楚，并通过Python来实现，每个设计模式都是围绕如下三个问题：

1. 为什么？即为什么要使用这个设计模式，在使用这个模式之前存在什么样的问题？
2. 是什么？通过Python语言来去实现这个设计模式，用于解决为什么中提到的问题。
3. 怎么用？理解了为什么我们也就基本了解了什么情况下使用这个模式，不过在这里还是会细化使用场景，阐述模式的局限和优缺点。

一些基本概念

在开始讲本次设计模式之前，我们先搞清楚软件设计中的一些基本概念吧。软件设计中我们有一个常用的概念叫“耦合”，我们常常说模块之间要“解耦合”，软件设计要“松耦合”。那么什么是“耦合”呢？
实际上耦合是指两个模块之间（模块可以理解为两坨代码，所以可以是函数，可以是类，或者更大范围的系统）发生了关系，比如一个模块调用了另一个模块的函数，或者一个模块需要获取另一个模块的数据，总之有了联系就有了耦合。所谓“解耦合”或者“松耦合”是说让两个模块之间的联系没有那么紧密，这样一个模块的变化不会影响另一个模块的代码。那么我们如何来使我们的系统是一个“松耦合”的系统呢？
实现“松耦合”最重要的就是抽象和一致性，白话就是要通过抽象的接口（Python中没有接口的概念，可以理解为抽象的类）来联系调用方和被调方。
一般的，假设我们实现了两个类A和B，我们可能会如下调用

classcall.jpg

代码可能是这样的

class A(object): def __init__(self): self.obj = B(param1, param2) def method_of_a(self): self.obj.method_of_b(param3) class B(object): def __init__(self, param1, param2): ... def method_of_b(self, param3): # do something .... 

但是这种情况下，如果B发生改变，或者想换成另一个类C，这时就需要更改A的代码，那么如果我们把A和B之间的联系抽象出来，通过接口（或者类似接口的东西）来连接A和B我们就可以某种程度上屏蔽这种变化，如下图所示：

interface.jpg

可能的代码如下：

class A(object): def __init__(self, some_obj): self.obj = some_obj def method_of_a(self): self.obj.consistent_method(param3) class B(object): def __init__(self, param1, param2): ... def consistent_method(self, param3): ... class C(object): def __init__(self, param1, param2): ... def consistent_method(self, param3): ... 

可以看出由于Python对参数没有类型约束，所以天然的支持接口，这也是Python灵活的地方之一。在这个例子中，我们的参数some_obj可以想象成一个抽象类或者Java中的接口，我们传递参数时可以传递具体实现类的对象（比如B或者C的对象），但在这里只是一个抽象。

另外，我们的B和C都实现了consistent_method，这就是一致性的体现。

为什么

假设我们设计了某种功能，当用户点击页面上的按钮时，我们需要为用户做两件事，一是做页面变换显示出预期的效果，二是响起特定的音乐。那么我们的代码可能是这样的：

def onClick(): changePage() playMusic() 

后来你的需求有变动，还需要记录用户点击时间，需要弹出提示信息，需要......
于是你需要不断的修改上述的代码，可能是这样的

def onClick(): changePage() playMusic() recordTime() popupHint() ... 

我们认为onClick()和这些功能函数耦合的过于紧密了，每次的改动都会影响onClick函数。这类问题抽象出来就是当一个事件发生时需要调用很多功能模块，而解决这类问题最好的方式就是观察者模式，也叫发布-订阅模式。

是什么

观察者模式是说你有一个观察者列表，这个列表中的函数或者某种功能都在观察某个事件的发生，一旦发生，这些函数或者功能就会自动执行，这个其实很好理解，如下图：

publisher_subscriber.jpg

我们还是上代码：

class Button(object): """publisher or subject""" def __init__(self): self.observer_list = [] def register(self, func): self.observer_list.append(func) def unregister(self, func): self.observer_list.remove(func) def onClick(): for func in self.observer_list: func() ... def playMusic(): """subscriber or observer""" ... def changePage(): """subscriber or observer""" ... ... def main(): button = Button() button.register(playMusic) button.register(changePage) ... 

通过这种方式，我们实现了发布者和订阅者之间的松耦合，它们之间并不直接联系，而是通过统一的register/unregister来绑定和解绑定。

怎么用

通过上面的代码，细心的同学可能会观察到似乎代码也没少啊，而且注册的时候不还是要修改代码去注册新的功能吗？能想到这的同学，你的批判性思维很好，鼓励一下！
这里基于以下几种好处我们要使用这个模式：

• 使用这个模式的最大好处之一就是灵活
  我们可以动态的修改监听的事件，比如用户不想在点击该按钮的时候响起音乐，那么当ta不选择这一项时，我们的程序可以灵活的通过unregister来解绑定，试想如果你不使用观察者模式，是很难解绑定的，你就需要去修改代码，显然这不现实。

# when user uncheck play music option
button.unregister(playMusic)

所以，使用这个模式的理由之一就是你需要动态的绑定和解绑相应的功能时，你就需要观察者模式。

• 第二个好处是代码复用
  比如你有很多个按钮，都需要统一的注册某些功能，这个时候你就可以实现一个父类，在初始化的时候将所有的需要注册的功能都注册好，子类直接继承就好了，子类当然还可以注册自己特殊功能。可能的代码如下：

class Button(object): def __init__(self): self.observer_list = [] self.observer_list.register(playMusic) self.observer_list.register(popupHint) def register(self, func): self.observer_list.append(func) def unregister(self, func): self.observer_list.remove(func) def onClick(): for func in self.observer_list: func() class ButtonA(Button): def __init__(self): super(ButtonA, self).__init__() ... class ButtonB(Button): def __init__(self): super(ButtonA, self).__init__() self.observer_list.register(changePage) ... 

好了，观察者模式到这里你就应该很清楚了，如果你觉得有收获，不妨点个赞，如果你觉得非常赞，那就打个赏，鼓励是一种美德！?