09年读过《Head First设计模式》，因为经验不足，并没有太大共鸣。 之所以重读，是因为这几年开发中遇到一些阻碍，如：需求频繁变更、团队内的人良莠不齐，希望能通过一些“经验”，来夯实项目底层模块，提高产品质量。
为何不读更经典的《设计模式 : 可复用面向对象软件的基础》？ 其实在2011年就买了《设计模式 : 可复用面向对象软件的基础》，但一直读不下去，只能当成词典查查，想精读却一看就困，真是无缘。
另外这几年反设计模式的文章没少看，避免为了模式而模式，keep it simple stupid，千万别把项目搞复杂了。
设计模式
模式是在某情境（context）下，针对某问题的某种解决方案。
- 情境就是应用某个模式的情况。这应当是不断出现的情况。
- 问题就是你现在某情景下达到的目标，但也可以是某情景下的约束。
- 解决方案就是所追求的：一个通用的设计，用来解决约束、达到目标。
面向对象基础
- 抽象
- 封装
- 多态
- 继承
面向对象原则
- 找出程序中会变化的方面，然后将其和固定不变的方面分离
- 封装变化
- 多用组合，少用继承
- 针对接口编程，不针对实现编程（针对超类型supertype编程）
- 为交互对象之间的松耦合设计而努力
- 类应该对扩展开放，对修改关闭（我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。）
- 依赖抽象，不要依赖具体类。
- 最少知识原则（墨忒尔法则）
- 由超类主控一切，由他们去调用子类
- 努力让一个类只分配一个责任
策略模式
定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法客户。
观察者模式
在对象之间定义一对多的依赖，这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并自动更新。
装饰者模式
动态地将责任附加到对象上。想要扩展功能，装饰着提供有别于继承的另一种选择。
工厂模式
- 抽象工厂模式 提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
- 工厂方法模式 定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
单件模式
确保一个类只有一个实例，并提供全局访问点。
命令模式
将请求封装成对象，将发出请求的对象和执行请求的对象解耦。
适配器模式
- 适配器模式 将一个类的接口，转换成客户期望的另一个接口。适配器让原本不兼容的类可以合作无间。
- 外观模式 定义了一个高层接口，让子系统更容易使用。
模板方法模式
在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以再不改变算法结构的情况下，重新定义算法中的某些步骤。
- 模板方法模式采用继承
- 策略模式采用组合
迭代器模式
提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部实现。
组合模式
允许你将对象组成树形结构来表现“整体/部分”的层次结构。组合能让客户以一致的方式处理个别对象和对象集合。
状态模式
允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
代理模式
为另外一个对象提供代理，以便控制客户对对象的访问，管理访问的方式有多种。
装饰者模式为对象加上行为，而代理则是访问控制。
复合模式
结合两个或者两个以上的模式，组成一个解决方案，解决一再发生的一般性问题。
MVC是复合模式，结合了观察者模式、策略模式和组合模式
- 模型使用观察者模式，以便观察者更新，同时两者解耦
- 控制器是试图的策略，视图可以使用不同的控制器实现，得到不同的行为。
- 视图使用组合模式实现用户界面，用户界面通常组合了嵌套的组件，像面板、框架、按钮