一、文章来由
按照惯例，来一个来由，这是《设计模式—可复用面向对象软件的基础》的读书笔记，整理给自己看的，整理的内容也会不断更新。大神轻喷~~如果不喜欢请留言说明原因再踩哦，谢谢，我也可以知道原因，不断进步
二、读书笔记
1、P12 可复用的面向对象设计的原则：
（1）针对接口编程，而不是针对实现编程。不将变量声明为某个特定的具体类的实例对象，而是让它遵从抽象类所定义的接口；
（2）优先使用对象组合，而不是类继承。理想情况下，你不应为获得复用而去创建新的构件。你应该能够只使用对象组合技术，通过组装已有的构件就能获得你需要的功能。但是事实很少如此，因为可用构件的集合实际上并不足够丰富。使用继承的复用使得创建新的构件要比组装旧的构件来得容易。这样，继承和对象组合常一起使用。
2、P14 委托
委托(delegation)是一种组合方法，它使组合具有与继承同样的复用能力。举例来说，我们可以在窗口类中保存一个矩形类的实例变量来代理矩形类的特定操作，这样窗口类可以复用矩形类的操作，而不必像继承时那样定义成矩形类的子类。也就是说，一个窗口拥有一个矩形，而不是一个窗口就是一个矩形。窗口现在必须显式的将请求转发给它的矩形实例，而不是像以前它必须继承矩形的操作。 
3、三种复用机制：
（1）继承和组合（继承是编译时静态定义，组合可在运行时确定）
（2）委托
（3）参数化类型，即template
4、P20 设计模式所支持的设计的可变方面
设计模式允许你独立变化的方面，你可以改变它们而又不会导致重新设计。
5、P33 工厂类和产品类
这里用到了多态，我在我的另一篇博文里面也提到过
6、P37 对变化的概念进行封装
在一给定平台上建立 Lexi 时，我们选择一个相应的版本。但想象一下，维护问题实在令人头
疼，我们已经保存了多个名字都是“Window”的类，而每一个类实现于一个不同的窗口系统。
另一种方法是为每一个窗口层次结构中类创建特定实现的子类，但这会产生我们在试图增加
修饰时遇到的同样的子类数目爆炸问题。这两种方法还都有另一个缺点：我们没有在编译以
后改变所用窗口系统的灵活性。所以我们还不得不保持若干不同的可执行程序。
既然这两种方法都没有吸引力，那么我们还能做些什么呢？那就是我们在格式化和修饰
时都做过的：对变化的概念进行封装。现在所变化的是窗口系统实现。如果我们能在一个对象中封装窗口系统的功能，那么我们就能根据对象接口实现 Window 类及其子类。更进一步讲，如果那个接口能够提供我们所感兴趣的所有窗口系统的服务，那么我们无需改变 Window 类或其子类，也能支持不同的窗口系统。我们可以通过简单传递合适的窗口系统封装对象，来给我们想要的窗口系统设定窗口对象。我们甚至能在运行时刻设定窗口。
这个总结一下就是：因为变化的地方是不确定的，可能会外包给很多人去写，所以要有一个统一的、稳定的接口，其他的封装成不同类。
7、P40 Bridge模式
