Observer一种行为模式

Observer被称为一种行为模式，用来构成运行中的对象间的关系。在“四人帮”的设计模式声明中提供的定义如下：


Java类库的java.util包中通过Observable类和Observer接口，实现了一个Subject-Observer模式的非通用版本。Observable类包含注册观察者的addObservers方法，用来象征观察对象发生改变的setChanged方法和发生任何改变时用来通知所有观察者的notifyObservers等方法。其中，notifyObservers方法可以接收一个任意类型的对象参数，这个参数将被广播给所有观察者。Observer接口将指定由notifyObservers调用的更新方法。这个方法需要两个参数：第一个参数是Observable的类型，这个是发生改变的内容；第二个是对象类型，是广播的参数。

当然我们也可以创建属于自己的类，而不是使用类库提供的类。但是当别人来维护我们的代码时，情况会不会很糟糕呢？所以我们还是用类库提供的例子。

让我们来看一个示例。假设我们家里有四个成员：妈妈、爸爸、一个婴儿和一条狗。当小婴儿哭了的时候，妈妈帮他换尿布，所以我们有一个Baby类的被观察对象和一个Mother类作为Baby的观察者：

当狗叫的时候，爸爸会带它出去走走。所以Dog是另一个被观察者，而Father是它的观察者：

乍一看，所有的事情都可以正常运行。但是，如果有人理解错了关系，把Mother作为了Dog的观察者（编译器不会报错，运行的时候会默默的为小狗换尿布，并且甚至不会警告我们犯了这么一个严重的错误）。

让我们来验证一下：

控制台输出的结果如下：

为了确保一个Subject-Observer关系被很好的建立，我们应该用Java 5的最好的功能之一：泛型。通过泛型可以让更多的bug在编译时就可以被检测出来，这样可以增加代码的稳定性。但这里有一个小问题，因为Obervable和Observer是Java docs中的一部分，我们不能也不应该改变它们。所以，我们可以去增加绑定，使用泛型签名来创建它们的子类而不是它们本身。通过泛型签名来编译泛型对象，但是运行的代码是子类文件。当代码还没有发布或者由别人来维护代码的时候，这个技术是很合适。

所以，我们可以通过类型参数S(Subject)和O(Observer)来替换Observable和Observer。这样在Observer的更新方法里，可以调用Subject所支持的所有方法而不需要预先进行类型转换。同样的，在Object的方法签名中我们也常常有机会用到泛型。所以，我们应该增加一个类型参数、一个使它和参数类型一致的参数。

这是两个泛型的第一版本的存根：

现在我们创建一个Mother-Baby关系，就可以正常运行了。如果是Mother-Dog会怎样呢？编译是正常的，但是这次在运行的时候抛出了ClassCastExeption（类型转换异常）。

所以，这显然还不够好，直到运行的时候才检测到了这个Bug。我们需要S在Observable范围内，那样它就可以作为一个参数传递给Observer；并且我们要求O在Observer的范围内，这样就可以作为一个参数传递给Observable。

这是我们修改后的最终版本：

在”The Java Generics and Collections”中定义了这种相互递归的类型绑定。

结论：Observer是一种具有很多实现的优秀设计模式，但是对于初级开发人员很容易受到蒙蔽而误用。增加相互递归绑定帮助我们在编译时就发现错误，并且当知道我们可以做得很好时晚上可以睡个好觉。