📒 《Head First 设计模式》读后记

抽象 封装 多态 继承

1. 策略模式
2. 观察者模式
3. 装饰者模式
4. 简单工厂
5. 工厂模式
6. 抽象工厂模式
7. 单件模式
8. 命令模式
9. 适配器模式
10. 外观模式
11. 模板模式
12. 迭代器模式
13. 组合模式

1. 组合而非继承。多用组合，少用继承

2. 封装变化。找到程序中会变化的方面，然后将其和固定不变的方面相分离。

3. 针对接口编程。针对接口编程，不针对实现编程。

4. 为交互对象之间的松耦合设计而努力。

5. 对扩展开放，对修改关闭。

6. 依赖倒置，要依赖抽象，不要依赖具体类。

   • 高层组件依赖低层组件，将其倒置，共同依赖抽象。
   • 倒置自己的思考方式，先思考低层组件，将其抽象，然后高层和低层组件都依赖此抽象(兑奖中心是高层，奖品是低层，先思考奖品，给奖品建立一个抽象类，奖品继承奖品抽象类实现自己，抽奖中间通过抽象奖品和工厂方法获取对应的奖品)
   • 变量不可以持有具体类的引用。
   • 不要让类派生自具体类，派生自一个接口或者抽象类。
   • 不要覆盖基类中已经实现的方法。
   • 以上三点不可能都完全遵守，正如所有的原则一样，我们都只能做到尽量遵循这个原则。

7. 最少知识原则(Least Knowledge)。只和你的密友交谈

   • 一个对象内我们尽量只调用属于以下范围的方法
     • 该对象本身
     • 被当作方法的参数传进来的对象
     • 此方法所创建或者实例化的对象
     • 对象的任何组件 （HAS-A关系，对象的某个实例变量对象）
   • 墨忒耳法则(Law of Demeter)，和它指的是一个原则。不过Law给人感觉是强制的，没有任何的原则是法律(Law)。
   • 优点：减少了对象之间的依赖，减轻了维护成本。
   • 缺点：更多的包装类被制造出来，以处理其他组件的沟通，复杂度和开发时间增加，并降低了运行性能。

• 好莱坞原则。别来找我，我会找你。将决策权放在高层模块，以便决定如何或者何时调用底层模块。与依赖倒置都是为了解耦。

• 单一责任。 一个类应当只有一个可引起变化的原因。

  • 一个类或者模块，由于其他类或者模块改动，那么它就也必须去改动，这个叫做可引起变化的原因。
  • 内聚（cohesion）这个术语度量一个类或者模块紧密地达到单一目的或者责任；如果只支持一组相关功能时，那称为高内聚反之为低内聚。