head first 设计模式，是比较有趣的一本设计模式的书。
在学校里看书和在工作时看书，意义是不一样的。在学校时是为读书而读书，我们可以从0到1，我们有的是时间。但是工作后就不一样。
我觉得这时的书更像是打通自己任督二脉的武功秘诀。在平时工作中，杂七杂八地学了一些东西，但是却不能融会贯通。所以还需要通过书来厘清你的思路。这是写本文的出发点，也是我的碎碎念！
看完该书后，转换成自己的语言，再表达出来，可能有错（那是一定的），但是，有总比没有好。如果有同学能够从中得到些启发，也算是自己的一种幸运吧！
我竟试图以一句话来描述一个设计模式！
1. 策略模式！
将统一的东西作为基类，可变的东西行为独立出来，在基类中通过变量进行引用，通过委托变量的方式，使用setter方法将委托变量改变，使其具有行为可变性。面向接口编程，而非面向类编程。其好处是，用同样的接口，通过不同行为类的传入产生不同的效果，便以改变行为变得容易。
2. 观察者模式！
类似于发布-订阅模式。存在注册服务，通知的过程。其实现方式可以理解为，注册服务时，将观察者加入到队列当中，当主题发生变更时，由主题主动依次从观察者队列中依次调用，从而达到通知主动推送的作用。其好处是，观察者随时注册观察可以实时收到消息，而被观察者对此一无所知，从而在达到通知的同时也解藕了。
3. 装饰者模式！
以某对象为主要对象，生成后，将其传入装饰者构造函数中，经过装饰后，再行输出的模式。该模式，可以许多散乱的方法独立组装出来，而不会影响其他变化，该模式是通过继承来实现的。典型的装饰者模式运用，java io 类的继承，有多个主类，及多个装饰类，从而方便用户操作想要的方法。其好处是，在大方向不变的情况下，可以反复更改主要的行为结果，对于一些附加类的变化，可以很方便地通过该模式进行数据再加工。
4. 工厂模式！
分为简单工厂模式-工厂模式-抽象工厂模式。所谓工厂模式，即是将需要的产品和工厂结合在一起，从而得到一个具体需要的产品的一个过程，而无需知道这个产品具体是由谁生产的。工厂模式很好的复用了多个产品的变化性，避免了在各个类中进行各自实例化从而导致类的散乱问题。或者从另一个角度来说，工厂只是某段复用性很高的代码的抽离而已。其好处是，统一把控了一些类的生成，避免了各个类散落在代码各个角落，从而给后期升级维护带来方便。
5. 单例模式！
就是全局只有一个实例对象的访问方式（单进程方式）。需要一个私有构造器，使外部无法实例化他，需要一个静态方法getinstance供外部访问实例使用，属于懒加载行为。但应注意多线程并发问题，从而创建两个instance，使用synchronized同步方法或者volatile同步本实例，从而解决并发问题，但是这会导致应用性能降低100倍的性能。当应用中大量使用单例，就得考虑是否合理了，因为适合单例的场景并不很多。其好处是，减少系统反复创建一个类时的性能开销及空间开销，且可以多处共享一些变量（如果需要的话）。
6. 命令模式！
将请求当作对象传递给另一对象，从而实现命令的执行方式。使请求与执行解藕开来，可以很方便地实现命令集操作，或者宏操作及回放。能够轻松实现日志队列操作。其好处是，将命令请求和命令执行分开，一般请求都会很快完成，但是执行却不一定，由于请求与执行分开，所以能够轻松实现事后补偿的动作。
8. 适配器者模式！
即实现A接口转换B接口的适配工作，如实现连接三角插座与两脚插头连接工作，适配器的意义在于不用改变或不能改变现有接口的同时，将新的接口接入现有环境，意义重大。其实现为，适配器继承目标接口，并传入被适配接口，将被适配接口的逻辑转换成目标接口的表述。可以继承多个接口实现双向转换。其好处是，不对现有代码进行改动的情况下接入新厂商的东西，适应原有方式。
9. 外观模式！
外观模式的意图在于提供简化的接口操作，同时，也不改变原有接口。其实现是一种类的包装简化。其遵循一个设计原则，只与最亲密的人交谈。其好处是，将原有复杂多变的接口转化为少且实用的几个接口，使外部调用时，只做最简单的事。
10. 模板方法模式！
在一个父类接口中定义一个算法骨架或者操作流程，并将一个子类特有的方法以抽象方法的方式暴露出来，使在运行时使用父类的操作流程调用子类的特有方法的方式。该模式可以省去许多机械代码，使子类只关注自己特有的部分。本模式中，还有一个平凡而重要的概念，钩子hook，钩子在java中表现出来就是，一个只有空的方法或者默认实现的方法，子类只要对该方法进行覆盖，就可以触发钩子，从而实现开关控制和自己的意图。因为是高层调用低层，所以存在有些操作的不明显，如果低层又调用高层的话，将很难搞清楚设计，因此应遵循一个原则，好莱坞原则，只有父类调用子类，子类不得调用父类，因此如果想知道框架中为什么要让你必须实现某个方法时，只需到父类中查看其调用一下便知，但不得私自调用父类方法。依赖倒置原则和这有点像。其好处是，将复杂流程封装起来，只提供可变的方法让子类重写，从而在父类调用，减少许多重复的代码。
11. 迭代器模式！
也就是实现像iterator 接口一样功能的方式，使对象能够不关注内部实现的情况下遍历元素。目前对我们来说，应该是没什么意义了，因为类似于for in 的语法，已经完全能够达到此类效果，该模式个人感觉没多大意义。其好处，就是为了方便使用的地方能够遍历出内部结构。
12. 组合模式！
即将多个接口具有的方法，组合在一起变为一个更大的接口，让操作者无需关注各类的差异，只管调用相同接口即可，但是对于有些子类没有的方法则需要抛出异常，以使外部进行捕获。使用场景得细细思量一番才行。这个功能，在gui编程时最明显，当你拖动几个系统提供的组件，在页面上组合出新的结构时，就是利用了组合模式了。
13. 状态模式！
与策略模式类似。其作用是控制外部操作在内部的状态流转，并无需让外部知晓，其操作其实是将一系列的if else解放出来，使逻辑更清晰。其实现为封闭整个流程的所有状态，在用户操作某一状态后，该状态只会做自己的事，并将状态转换到下一状态，用户进行下一操作时，内部已改变，但是对类内部来说，操作的仍是单一状态，因此逻辑清晰。但是该模式会产生大量状态类，增加大量代码，且需抽象出良好的状态，比较考验技术水平。其作用是，便逻辑更清晰，也更容易扩展。
14. 代理模式！
即访问对象不通过直接访问的方式，而是去访问代理让代理去跟具体对象沟通，沟通好后将结果返回给访问者，这里一般会涉及到rmi远程调用，代理模式减小了系统的复杂度（至少到调用者是的）。虚拟代理，缓存代理，同步代理，防火墙代理，写入时复制代理。代理模式在现实中用的是非常广泛的，他为我们屏蔽许多复杂细节，由框架提供的代理，使我们操作方便的同时，也让我们变得傻瓜。
15. 复合模式！
即组合混合使用了多个模式的模式，该模式准确说不算是模式，但是也在框架中体现的最多的模式，如著名的mvc。组合策略，适配器，观察者，装饰器，组合模式，工厂等等。其好处是，在基础模式的基础上，再封装出另一实用模式，解决更具体的应用场景问题。
16.更多！
模式是某种情境下针对某种问题的某种解决方案。其他模式，访问者模式，中介模式，原型模式，桥接模式，责任链模式，。反模式，即不好的模式，表面看起来好，实际用之后会有大坑。
没有最好，只有最合适。这句也非常适合于描述设计模式。另外，在工作中试着用用套路，然后再从套路中走出来，这叫成长。