设计原则:
1. 找出应用中可能需要变化之处,把他们独立出来,不要和那些不需要变化的代码混在一起.
2. 针对接口编程,而不是针对实现编程.
例如: dog和cat继承于animal
针对接口编程：dog d = new dog();
d.makesound();
针对实现编程: animal a = new animal();
a.makesound(); 利用多态调用
3. 多组合，少继承（组合和委托可以在运行时动态扩展,达到继承的效果,然而继承是编译时就决定了的,缺
少弹性和不好的维护性）
4. 为了交互对象之间的松耦合设计而努力
5. 类应该对扩展开放,对修改关闭
6. 要依赖抽象,不要依赖具体类
7. 最少知识原则，只和你的密友谈话.（适配或者外观的重要性）
设计模式：
1. 策略模式 （鸭子） //算法的抽象与解耦,使得算法容易替换,而不影响具体的类
定义了算法簇,分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户.
鸭子的设计模式: 委托--》封装--》抽象
2. 观察者模式（observer）（天气预报与画板） //消息响应的一种机制
出版者 + 订阅者 = 观察者模式
定义了对象之间的一对多的依赖,这样一来，当一个对象改变状态的时候,它的所有依赖者都会收到通知并
更新.
subject(出版者)接口 需要有注册和删除observer的方法,以及通知observer的方法
observer(订阅者)接口 需要有响应出版者消息的方法
3. 装饰者模式 （咖啡及原料） //属性不同时而展现的不同状态,通过装饰来修改对象,而不需要添加新类
动态的将责任附加到对象上,若要扩展功能,装饰者提供了比继承更有弹性的替代方案.
a. 抽象组件 --》 实体组件 （通过添加装饰类动态添加方法,再装饰实体达到扩展）
b. 抽象组件 - 》 抽象装饰者 --》 具体装饰者
具体装饰者通过再实体组件上面构造,再添加具体装饰上去,形成新的组件.（通过添加装饰者类动态添加
方法,再装饰实体达到扩展）
4. 工厂模式 （各种风格的pizza） //封装对象的创建过程
所有工厂都是用来封装对象的创建,让我们是针对抽象编程,而不是针对具体类编程.
a. 简单工厂
把所有创建工作委托给工厂去做,通过不同的工厂制作出不同的产品
b. 工厂方法（继承）
定义了一个创建对象的接口,但由子类决定要实例化的类是哪一个.工程方法让类把实例化推迟到子类.
创建者类: creater抽象类 --》 具体方法的creater（工厂）
产品类: 产品抽象类 --》 具体产品类
c. 抽象工厂模式（对象组合）
提供一个接口,用于创建相关或依赖对象的家族，而不需要明确指定具体类（即接口不关心具体的产品
类是什么）.
抽象产品类由工厂接口组合而来.
5. 单件模式 //若是全局的变量,需要在启动的时候实例化它,存在弊端
确保一个类只有一个实例,并提供一个全局的访问点.
static的单件对象，private 的构造器，static 的getinstance()方法,不存在的时候就创建,存在则不创
建
6. 命令模式(遥控器按钮操作多个对象) //各种各样的命令请求
将请求封装成对象,以便使用不同的请求,队列或者日志来参数化其他对象.命令模式也支持可撤销的操作.
命令发送者: 命令对象 + 事件方法(调用到命令对象的execute())
命令对象: 包含具体的执行者
7. 适配器模式和外观模式 （不同的对象之间的交流或者一处理多个任务的情况）
a. 适配器模式 （鸭子与火鸡）
将一个类的接口,转换成客户期望的另一个接口.适配器让原本不兼容的类可以合作无间.
对象适配器: 适配器继承客户需要的目标接口,并委托被适配对象处理
类适配器： 适配器继承于客户需要的目标类和被适配类,再实现内部方法转换
b. 外观模式 （家庭影院,遥控器控制）
提供了一个统一的接口,用来访问子系统中的一群接口.外观定义了一个高层接口,让子系统更容易使用
. 客户将一切操作委托给外观,外观再处理子系统的响应.