可以用下面的方法让你的大脑就范

1. 慢一点，你理解的越多，需要记的就越少。
2. 勤做练习，自己记笔记。
3. 上床睡觉之前不要再看别的书了，或者至少不再看其他有难度的东西。
4. 要喝水，而且要多喝点水。
5. 大声说出来。
6. 听听你的大脑怎么说。
7. 要有点感觉！
8. 设计一点东西！

要点

1. 知道 OO 基础，并不足以让你设计出良好的 OO 系统。
2. 良好的 OO 设计必须具备可复用、可扩展、可维护三个特性。
3. 模式可以让我们建造出具有良好的 OO 设计质量的系统。
4. 模式被认为是历经验证的 OO 设计经验。
5. 模式不是代码，而是针对设计问题的通用解决方案。你可把它们应用到特定的应用中。
6. 模式不是被发明，而是被发现。
7. 大多数的模式和原则，都是着眼于软件变化的主题。
8. 大多数的模式都允许系统局部改变独立于其他部分。
9. 我们常把系统中会变化的部分抽出来封装。
10. 模式让开发人员之间有共享的语言，能够最大化沟通的价值。

设计原则

1. 封装变化。找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。P9。

   把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩张此部分，而不影响不需要变化的其他部分。

2. 针对接口编程，而不是针对实现编程。P11。

   “针对实现编程”的做法：Dog d = new Dog();d.bark();

   “针对接口编程”的做法：Animal animal = new Dog();animal.makeSound(); 或者：Animal animal = getAnimal();animal.makeSound();

3. 多用组合，少用继承。P23。

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

5. 类应该对扩展开放，对修改关闭（开闭原则）。P86。

6. 要依赖抽象，不要依赖具体类（依赖倒置原则）。P139。

   不要让“高层组件”依赖“低层组件”，而且，不管“高层组件”还是“低层组件”，两者都应该依赖于抽象。
   避免违反该原则的几个方针：

   1. 变量不可以持有具体类的引用。
      如果使用new，就会持有具体类的引用，可以使用工厂来避开这种引用。
   2. 不要让类派生自具体类。
      如果派生自具体类，就会依赖具体类，可以派生自抽象或接口。
   3. 不要覆盖基类中已实现的方法。
      如果覆盖基类中已实现的方法，那么基类就不是一个真正适合被继承的类。基类中已实现的方法应该被所有子类所共享。

7. 最少知识原则：只和你的密友谈话。P265。

   解释：当你设计一个系统时，不管是任何对象，你都要注意与它交互的类有哪些，并注意它和这些类是如何交互的，尽量避免过多的类耦合在一起，带来维护成本的上升。这个原则推荐的一些方针：就任何对象而言，在该对象的方法内，我们只应该调用一下范围的方法：

   • 该对象本身

   • 被当作方法的参数而传递进来的对象

   • 此方法所创建或实例化的任何对象

   • 对象的任何组件。

     如果对象是调用其他的方法的返回结果，不要调用该对象方法。

     public float  getTemp(){
       //  没有采用该原则
       Thermoment thermoment = station.getThermoment();
       return thermoment.getTemperature();
     }
     
     public float getTemp(){
       // 采用该原则
       return station.getTemperature();
     }

8. 别找我，我会找你。P296。

   高层组件对待底层组件的方式是“别调用我们，我们会调用你”。

   模板方法模式，工厂模式，观察者模式，都使用了该原则。

   好莱坞原则和依赖倒置原则：

   • 依赖倒置原则教我们尽量避免使用具体类，而多使用抽象。
   • 而好莱坞原则是用在创建框架或组件上的一种技巧，好让低层组件能够被挂钩进计算中，而且又不会让高层组件依赖底层组件。
   • 两者的目标都是在于解耦。

9. 单一责任：一个类应该只有一个引起变化的原因。P339。

书中类图示意