很长一段时间前，看了一部分书，写了些笔记，由于某些原因中断了，今天重新拾起这本书，要继续看下去～～
以下是上次的笔记，重新开始～
1. OO原则：
1.1.封装变化
指的是设计过程中，设计者应当充分考虑将来可能会发生变化的代码部分，将它们提取并封装起来。
1.2.多用组合，少用继承
即多使用has-a的关系，少用is-a的关系。若过分依赖继承，当父类的功能发生变化以后，将会影响到所有的子类。不利于代码的修改。而组合则是将各个功能独立成接口，被类使用，可以很容易的实现功能的组合使用。
1.3.针对接口编程，不针对实现编程
与上一条原则有联系。继承方式实现的功能扩展需要在每个子类的实现中编写扩展的功能；而组合方式实现的功能扩展只需要增加一个接口，代码维护会更容易。
1.4.为交互对象之间的松耦合设计而努力
交互对象之间的信息究竟通过何种方式传递？我们应该设计出更好的方案来使交互对象之间的耦合不是那么紧密。这条原则与后面的“观察者模式”有关
1.5.类应该对扩展开放，对修改关闭
我们应当通过良好的设计，尽量满足这个原则，在不用修改原有代码的基础上进行功能的扩展。看似不可能，后面的很多设计模式都在为这个原则而努力。
1.6.依赖抽象，不要依赖具体类
这个原则还有一个响亮而正式的名称：“依赖倒置原则”。这个原则跟1.3很像，但是这里更强调抽象。这个原则说明了：不能让高层组件依赖底层组件，而且，不管是高层还是底层组件，都应该依赖于抽象。
2. 设计模式：
2.1.策略模式
定义了算法簇，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。该模式主要是为了解决上面的1.1、1.2和1.3原则的使用问题。
2.2.观察者模式
定义了对象间的一对多依赖，这样依赖，当一个对象改变状态时，它的所有依赖者都会受到通知并自动更新。Java为这个模式提供了内置的支持（java.util包，Observer接口和Obserbable类）。该模式是为了解决上述的1.4原则的使用问题。
2.3.装饰者模式
动态的将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。该模式很好的解决了1.5提到的开发-关闭原则。
2.4.工厂模式
定义了一个创建对象的接口，但由于子类决定要实例化的类是哪一个。工厂方法把实例化推迟到子类。也就是说，工厂方法把对象的创建部分提取出来，有利于多样性的对象创建，而不用修改每一个子类。
2.5.抽象工厂模式
提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。这样就等于说是有一个抽象的工厂，定义了制造的接口和流程，供子类具体实现每个接口。一般来说，抽象工厂模式中的每个接口都是通过工厂模式来实现的。该模式解决了1.6原则的使用问题。
2.6.单件模式
确保一个类只有一个实例，并提供一个全局访问点。
这是如何做到？我们可以使用私有构造函数，并通过一个静态共有成员函数来创建对象。具体实现不再详述。
暂完，
待续。。
