## 一、观察者模式定义 观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题。这个主题对象在状态发生变化时，会通知所有的观察者对象，使他们能够自动更新自己。 解析：为什么会有观察者模式？ 这里需要注意几点： 1、**一对多的依赖关系；**并不是说一对一不可用，只是一对一用观察者模式，没有必要。 2、**观察者接收到主题的通知后，自动更新状态：**观察者本身都有自己更新自己的方法，需要通知者这个触发者来触发，即观察者在主题达到某个条件后，开始自动更新。 ## 二、看类图，找要点  从类图中可以看到图中有四个类：一个抽象通知者，一个具体通知者，一个抽象观察者，一个具体观察者。 具体观察者用来监听主题变化，注意图中没有主题类，有的是通知者，也就是说，主题通过通知者来通知观察者变化。 **1、观察者** 一对多的依赖关系就是指主题跟观察者之间的关系，继承自Observer的ConcreteObserver可以有多个。 SO，具体观察者共有的特点就是：Update方法的参数类型相同，返回值相同。只有这样的观察者才可以使用观察者模式。 **2、通知者** 具体通知者ConcreteSubject是通过实现一个接口Subject来实现通知任务的。既然有接口，很明显，可以有多个通知者，不同的通知者有各自对应的主题。 **3、观察者模式中的逻辑判断**——通知者方法（attach：增加观察者；detach：移除观察者） 方法中有增加，又有移除，意味这什么？ 我们可以在一个主题中通知中，实现多次**逻辑判断**执行操作。例如：机房收费系统中的上机操作：在插入上机记录之前，需要通知三个观察者：卡号是否存在；卡内余额是否充足；查询卡状态；好了，接下来的逻辑判断是：如果前边三个条件满足，则通知以下这两个观察者：插入上机记录，修改卡状态。有了Attach 和Detach 这两个方法后，我们可以先添加前三个观察者，执行完后，判断结果，然后用Detach 方法把之前的观察者去掉，再Attach 新的观察者。去执行各自的操作。 ## 三、实践 以机房收费系统为例，简单列出几个适合用到观察者模式的有：上机，下机，充值，注册，结账前的统计工作。 用图形化的语言表示如下：（图中没有结账）  **既然可以有逻辑判断，观察者还可以同时调用观察者自己的多个方法。** 看结账观察者：  图中没有抽象通知者，我自己给去掉了。为什么有抽象观察者，是为了降低耦合度才有的，而且像第一种情况那样，抽象观察者必须得有，但是结账这个观察者模式，我单抽出来，把它的更新方法做成两个，在系统中，这样的情况，貌似只有一种，所以我觉得把抽象通知者去掉，反而更简洁。 PS ：这个结账的主题和观察者也可以合并到第一种情况中，在这里我只是为了说明 **1、观察者可以有多个更新自己的方法；** **2、抽象观察者，在小的系统中，或者只有一个主题的通知者中可以省去；** 而特意拿出来的。 结语：这些只是个人见解，欢迎指正。