单一职责原则

应该只有一个引起类变化的原因

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方法接受一个具体的实现类，该类实现实现接口
• 具体功能不直接依赖于实现，而依赖实现接口
• 添加功能时，继承原有的功能类，添加新功能方法即可
• 需要不同实现时，给功能类注入不同实现对象