观察者模式

 读完 《HeadFirst 设计模式》后，我谈谈自己的理解，如果觉得不对的话，欢迎您的批评！

如果该模式是一对多的话，那么为什么通知者要实现一个接口呢？

我的理解是这样的：实现了这个接口的就是通知者，只是起了一种概念的作用，对程序并没有实际影响！

既然没有实际什么影响，那为什么不是继承一个抽象类呢？抽象类也可以起到类似的作用啊？

我想：从概念("一")来讲的话，抽象类更多的是继承概念(也就是"多")，所以并没有接口合适。

　　    其次，因为它是抽象类，所以继承它的类不能在继承别的类，这很不方便。

 

那为什么观察者是实现一个接口，而不是实现一个抽象类呢？

这个和上一篇文章一样：可能存在多个观者者的更新方法是相同的，如果用接口的话就能避免写重复的代码。

我们可以把观察者的不变的部分放在一个基类里面，然后继承该类，再实现接口。这样就就完美解决了问题。

 

那么如果该模式是多对多的话呢，通知者该用接口还是用抽象类？

众所周知：通知类一般包含这几个方法(addObserver,deleteObserver,notifyOberver)

如果方法是多变的话，你会发现其实不管是用接口还是抽象类，都有可能写重复的代码。

因为你可能希望添加观察者的同时干点什么事(A)，或者删除观察者的同时干点另外的事(B)。

总有一些观察者会处于(A,C)，或者(D,B) 这种情况。所以这时用抽象类还是接口没什么区别。

不过用接口有一个优点，就是实现接口的同时可以继承一个类。

你可能会想，那我不如把那几个方法都拆开变成接口，这样不就没问题了吗？

如果你这么想，确实没有问题，但是确不太让人容易理解，那几个方法从意义上来说应该是一体的。

如果你不嫌麻烦的话的确可以这么做，但是代码阅读起来就会比较困难了。

 

那么如果方法是不变的呢，你可能会想，既然方法不会变，那我不如用类好了。

Java 内置的观察者模式就是这样的，这意味着你在继承该类的同时，不用再写那几个方法了。

但是同样他也带来一些问题，你不能决定那几个方法的细节部分，继承该类的同时你不能继承其他类。

欢迎各位指正，谢谢！