设计模式之观察者模式（三）
又和大家见面了。首先，和大家说声抱歉，之前的几篇文章，可能条理清晰之类的做的不太好，每篇文章的篇幅也比较长，小编在收到读者的建议之后， 也是认真的思考了一番。之前的想法是尽量把一个模块介绍完，没想到一个模块写着写着就写长了。在之后的文章里，需要认真分段，做到能简洁就简洁，能分块就分块，在利用大家碎片化的时间里，力争短小精悍又能收获颇丰。
之前的观察者模式，介绍了自己动手编写一套观察者模式，以及使用java内置的观察者模式来进行实现。分了两篇，并且知道了，观察者模式是基于发布和订阅的，主要由两种模式
- 拉模式
目标角色发生变化之后，仅仅告诉观察者角色已经发生变化了；观察者角色如果想要知道更详细的内容以及变化细节，就需要自己去获取，比如通过getter方法。 - 推模式
通知你发生变化的同时，把变化的信息发送到观察者角色中去。推模式就是无论观察者是否需要这个信息，都会无条件的收到。
这两种模式的使用，取决于功能需求。如果目标角色错综复杂，并且观察者角色进行更新时必须得到一些具体变化的信息，那就适合用“推”；如果目标角色简单，又不需要每次都获取变化信息，那就用“拉”。
在jdk中，也有观察者模式的实际使用场景。比如swing api的jbutton。jbutton的超类abstractbutton中有许多增加和删除（listener）的方法，其实就是观察者模式的提现。考虑到现在swing的实际使用场景并不多，在这里就不进行赘述啦，感兴趣的朋友可以看看java源代码，或者去实践下。
设计箱内的工具
这个工具其实在之前策略模式的时候总结过，但是并没有通过标题的方式单独给大家介绍，在之后的总结里，把这个单独加上，这个还是比较重要的。我们通过一步一步的学习，积累一个个工具，设计模式就不会很难啦。
-
oo基础
抽象、封装、继承、多态
-
oo原则
封装变化
多用组合，少用继承
针对接口编程，不针对实现编程
为交互对象之间的松耦合设计而努力（这是本次的新原则。松耦合设计更有弹性，更能应对变化）
-
oo模式
『策略模式』
『观察者模式』--在对象之间定义一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象就会收到通知，并自动更新。（就是我们新学习的模式，以松耦合方式在系列对象之间沟通状态。mvc是观察者模式的代表，后续会有机会介绍的哦）
挑战设计原则
这次也涉及到了设计原则，之前没有过多的介绍。那么，观察者模式是如何遵循设计原则的呢？别急，马上给你
- 找出程序中会变化的方面，然后将其和固定不变的方面相分离
在观察者模式中，会改变的是主题的状态，以及观察者的数目和类型。用这个模式，你可以改变依赖于主题状态的对象，却不必改变主题。这就叫提前规划！
- 针对接口编程，不针对实现编程
主题与观察者都是用接口；观察者利用主题的接口向主题注册，而主题利用观察者接口通知观察者。这样可以让两者之间运作正常，又同时具有松耦合的优点
- 多用组合，少用继承
观察者模式利用“组合”将许多观察者组合进主题中。对象之间的这种关系不是通过继承产生的，而是在运行时利用组合的方式而产生的。
至此，小编就学完了观察者模式。相比较于书本，小编把观察者模式的其中一些更好的概念理解缩减了，只单独举了一个报社订阅报纸的例子来做进一步的解释。以及模式中的“推”和“拉”是如何引出而来的，也没有细说，在这节里把推和拉的特点进行了描述，并给出了一点拙见。
有留言给小编说图的来源，以及是否需要有画图的能力。我把我在知识星球里的回答放出来，只是自己的一点感悟，如有不对的地方，可以留言给小编修正。『设计模式归根到底还是需要一个思想，画uml图是为了更加深刻理解软件工程中的知识。优秀的写代码的程序员不一定能画好uml图，能画好uml的一定是个优秀的程序员（我是这么理解的），很多公司都不需要画图，因为只要实现功能即可，这个能力，需要自己平时培养的。我画uml图也不太好，还停留在大学老师教育的阶段，所以跟着这个学习，画图理解能力还提升了，也是另一种收获吧。类图、时序图、用例图都是比较重要的，掌握了能加深对软件工程的理解』
观察者模式就到这里为止了。下一模式是装饰者模式，就如开头所说，小编会用心分块，力争短小精悍，让各位的碎片化时间得到更充分的利用。
推荐阅读
github地址 headfirstdesign