软件开发过程中的视角
概念 软件要负责的是什么
规约 怎么使用软件
实现 软件怎样履行自己的职责
设计模式要求从高层次视角考虑问题。
功能分解模块化 会带来低内聚，紧耦合，难以修改维护
不能将责任集中，要分散到各个应该为其负责的类
设计模式书中对设计的建议：
1按接口编程
2尽量用聚合代替继承
3找出变化并封装起来
Facade 用于简化接口
Adapter 用于匹配已有接口
传统模式下的对象：对象包装数据，提供方法
设计模式下的对象：对象是具有责任的实体
传统模式下的封装：用于隐藏数据
设计模式下的封装：用于隐藏一切
传统模式下的继承：用于特化和复用
设计模式下的继承：将类按相同行为分类
找到变化的地点：共性分析
找出如何变化：变性分析
敏捷编程方法关注以下品质 1无冗余 2可读 3可测试
关注可测试性可以帮助程序强内聚、松耦合。
某个规则只在一个地方实现
Strategy 对算法或规则进行抽象
Bridge 将抽象和实现分离，使其独立变化
Abstract Factory 用于创建一系列相关类。使类的使用者与类的创建过程解藕。
从部分构造整体，不可能得到优美的设计。
设计是一些列复杂化的活动，结构是通过对整理操作、使其起皱而注入其中的，而不是通过一小部分一小部分添加而成，在分化的过程中，整体孕育了部分，整体的形式及其各个部分是同时产生的。分化的过程好像是胚胎的成长过程。
开始用最简单的术语来考虑问题(概念性层次)，然后添加更多的特性，在此过程中设计将越来越复杂，因为我们加入了越来越多的信息。
高层模式为其他模式建立背景。
开闭原则：对扩展开放，对修改封闭。
尽量用接口，少用抽象类。
依赖倒置原则
高层模块不应该依赖于低层模块，高层模块和低层模块都应该依赖于抽象。
抽象不依赖于细节，细节应该依赖于抽象。
使用对象和被使用对象之间只能在概念层次存在耦合，而非实现层次。
一个从基类派生的类应该支持基类的所有行为。
设计模式有助于看到什么地方可能出现变化，而不是会出现哪个具体的变化。
不让一个类封装两种变化，除非这些变化明确地耦合在一起。
采用共性和可变性分析，有助于解决问题。
客户经常用“总是”表达“通常”，用“从不”表达“很少”
分析矩阵可以辅助分析复杂的问题。
Decorator 把一系列对象串成一个链，依次执行。
Observer 订阅通知。
Template Method 将共同的部分实现，将不同的部分留给子类完成。
对象应该要么构造和/或管理其他对象，要么使用对象，而不应该兼而有之。
Singleton 确保某个类只有一个对象被实例化，用于单线程
Double-Checked Locking 确保某个类只有一个对象被实例化，用于多线程
有状态的Singleton应该谨慎使用，因为这样的全局数据可能会使系统的不同部分耦合。
Object Pool 创建并管理多个资源。
Factory Method 使一个类的实例化延迟到其子类。
模式不是最重要的，模式背后的理念和原则才是最重要的。