设计模式的八个原则：
- 依赖倒置原则：高层次的代码（稳定）不应该依赖低层次的代码（变化），高层次的代码应该依赖于抽象。抽象的代码不应该依赖实现细节，实现细节应该依赖抽象。
- 开放封闭原则：类模块应该开放扩展的，而其原先的代码尽量封闭不可改变。
- 单一职责原则：一个类应该仅有一个变化的原因，该变化隐含了它的职责，职责太多时会导致扩展时对代码东拉西扯，造成混乱。
- 替换原则：子类必须能够替换它的基类（IS-A），继承可以表达类型抽象。
- 接口隔离原则：接口应该小而完备，不该强迫用户使用多余的方法。
- 优先使用组合而不是继承：继承通常会让子类和父类的耦合度增加、组合的方式只要求组件具备良好定义的接口。
- 封装变化点
- 针对接口编程，而不是针对实现编程。
要解决的问题
软件中面临的挑战来自于变化，如各种业务的变化导致我们去不停的修改软件。设计模式就是解决变化的问题，但是要明确的是，设计模式不是让变化消失，而是缩小变化的范围，如一只小猫在满屋子乱跑，会搞得满屋子都很混乱，但是如果将猫关在笼子里，那么混乱只会发生在笼子里，所以设计模式的核心就是把变化关在笼子里，不让变化漫延的到处都是，就可谓好的代码，好的设计。设计模式的要点是“寻找变化点，然后在变化点处应用设计模式，从而来更好地应对需求的变化”.“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。
重构的关键技法
静态->动态
早绑定->晚绑定
继承->组合
编译时依赖->运行时依赖
紧耦合->松耦合
设计模式分类
组件协作：
• Template Method
• Observer / Event
• Strategy
单一职责：
• Decorator
• Bridge
对象创建:
• Factory Method
• Abstract Factory
• Prototype
• Builder
对象性能：
• Singleton
• Flyweight
接口隔离:
• Façade
• Proxy
• Mediator
• Adapter
状态变化：
• Memento
• State
数据结构：
• Composite
• Iterator
• Chain of Resposibility
行为变化：
• Command
• Visitor
领域问题：
• Interpreter
