单一职责原则
应该只有一个引起类变化的原因
example：
修改之前，存在一个严重错误，用户的属性和对用户的操作在一个类中：
修改前，用户属性和对用户的操作在一个类中
实际情况中，把用户和对用户的操作分成两个类更合适一点：
修改后,分开两种类型的操作
example2:
电话类，有拨号、挂断、通话三个方法：
可以将其中拨号、挂断两个方法放在单独接口中，因为它属于协议管理方法；而通话属于数据传送：
当手机可以上网时，对外的接口不改变。
example3:
把一堆功能放在一个函数，用选项来确定内部逻辑：
])
修改后：
;+changeAddress(User user);+changeTel(User user)])
明确每个函数的功能，不要大杂烩方法。
- 不要设计超级大的接口，功能杂糅的接口，应该只有一个使得它改变的原因。子类实现大的接口，需要实现所有方法，侵入了子类。
- 接口的划分没有绝对正确的标准。
里氏替换原则
所有引用父类的地方，可以透明的替换成子类。
- 子类要扩展父类的方法，不要更改原来的方法
- 父类可以将方法声明为final，明确告诉子类不要更改父类行为
- 常说的继承是is-a关系。实际上，不仅仅是现实世界语义上的is-a关系，更重要的是行为上的is-a关系，即不要更改父类方法的原有含义。（想起了go/ruby的duck类型，我不管你是不是继承了子类，我只关系你行为是不是符合语义，只要行为符合，我都认为是子类）
- 想想一下，有人在子类，把父类小于less()方法复写为大于语义，不知道的人，替换成新子类的时候，心中一定是日了狗了。
- 子类方法语义和父类不同，就不敢透明替换
- 只有符合了里氏替换原则，才会符合开闭原则。假设调用父类的地方，都不能安全的替换为子类，那么“对扩展开放”也就不可能。
- 对于父类的合法输入，对于子类一定合法；子类的输出，一定被父类的输出包括。
依赖倒置原则
高层和底层之间不直接产生依赖关系，上层使用下层的接口。
- 不要直接去依赖其他类，而是去依赖他的抽象，以后想替换也比较容易
接口隔离原则
将接口按将来可能的变化，划分为几个接口，每个接口独自变化。
- 接口划分时，要满足单一职责原则，并且接口要有内聚性。
- 少一个接口方法，就少一个public方法，对外改动的风险就越小。
- 划分是有粒度的，越小越灵活，越能提供定制化的服务，但是复杂度增加了。
说白了，接口是筋骨，不要太肥！太肥会拖累子类，而且会让别人没发实现这种接口。
迪米特法则
让使用者只关心公布的接口和方法。
- 公开的方法越多，修改越麻烦，变更风险越大
- 类方法只和成员变量、输入输出参数的类产生联系，不和其他陌生类产生联系。
- 通过构造函数、set方法将依赖对象注入
- 和其他类解耦，会产生中转依赖的方法
开闭原则
对扩展开放，对修改关闭
- 使用扩展子类来面对需求变化，而不是更改原来的代码
- 通过接口或抽象类来约束扩展的行为
- 尽量依赖抽象，而不是具体的实现类（这点很好理解，尽量面向抽象编程，而不是面向实现编程）
- 抽象要保持稳定
单例模式
迭代器模式
- 集合接口，声明iterator()方法
- 迭代器接口Iiterator，声明迭代器方法方法：next(),hasNext()，外界通过接口方法来访问集合
- 具体迭代器类，对应于下面的具体集合类。该迭代器知道如何遍历集合。构造函数传入具体的集合对象
- 具体集合类，实现集合接口，在iterator()方法中返回迭代器实例，并传入this实例。
- 调用方使用集合iterator()方法获得迭代器实例，对集合进行遍历
适配器模式
实现方式1:
- 声明外部需要使用的适配器接口
- 适配器实现该接口，并从要适配的类继承
实现方式2: - 声明外部使用的适配器接口
- 适配器实现该接口，并使用适配对象实例完成操作
模版方法
- 声明模版父类，需要子类实现的模版方法为抽象方法
- 模版类把不可更改的主流程声明为final方法，避免子类复写
- 子类继承模版父类，实现模板方法
- 模版类的主流程、确定的流程方法使用final修饰，在一定程度上确保里氏替换原则。
- 子类实现要符合里氏替换原则
- 模版方法会让人理解困难，必须同时知道子类和父类在干什么
原型模式
- 具体的产品类继承clone接口，实现clone方法
- manager类实现管理复杂的，从clone方法生成的对象
桥接模式
- 声明功能类的基本类，实现基本功能
- 声明实现接口
- 功能类通过构造函数或者set方法接受一个具体的实现类，该类实现实现接口
- 具体功能不直接依赖于实现，而依赖实现接口
- 添加功能时，继承原有的功能类，添加新功能方法即可
- 需要不同实现时，给功能类注入不同实现对象
