设计模式

单一职责原则（single responsibility principle）

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

一个类应该是一组相关性很高的函数、数据的封装。

开闭原则（open close principle）

对修改关闭，对扩展开放

一个类一但完成，只能因错误而被修改。（修改容易引入bug）
尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。（可以通过继承、依赖注入等方式）

里氏替换原则（liskov substitution prinsiple）

所有引用父类的地方必须能透明地使用其子类

看到父类地地方，换成子类也完全没有影响。
这原则靠的是：继承和多态
意思差不多就是：依赖抽象而不是具体实现

里氏替换原则和开闭原则是生死相依、不离不弃的，这两个都强调“抽象”，运行时替换抽象

依赖倒置原则（dependence inversion principle）

模块间的依赖通过抽象发生，实现类之间不应该发生直接依赖关系，其依赖关系是通过接口或抽象类产生的。（叫面向接口编程或面向抽象编程）

  定义成员变量，应该是定义成其接口或父类。
  不要用具体的类，而是用抽象类。
  依赖抽象

依赖倒置.png
参考这里

接口隔离原则 （interface segregation principles）

客户端不应该依赖它不需要的接口
类间的依赖关系应该建立在最小的接口上

将大的接口拆分为小的接口
让客户端依赖的接口尽可能的小

迪米特法则 （law of demeter）（最少知道原则 ）

一个对象应该对其他对象有最少的了解

only talk to your immedate friends （只与直接的朋友通讯）
大白话：能看到一个类的地方，就尽量不要看到两个或更多的类。

软件设计原则.png

合成/聚合复用原则

尽量使用合成/复用原则，尽量不要用类的继承

• 合成：强拥有关系，体现了部分与整体不可分。
• 聚合：弱拥有关系，不是必须的。

合成、集合UML.png

好处：保持每个类被封装，并集中在单个任务上，使得类与类继承保持较小规模。

继承的优缺点

优点：

• 1.代码重用，减少创建类的成本，每个子类都拥有父类的属性和方法
• 2.子类和父类基本相似，但又与父类有所区别
• 3.代码可在子类中得以扩展

缺点：

• 1.继承是侵入性的，只要继承就必须拥有父类的所有属性和方法
• 2.可能造成子类冗余、降低灵活性，因为子类必须拥有父类的属性和方法
• 3. 增强了耦合性。 当父类的常量、 变量和方法被修改时， 需要考虑子类的修改， 而且在缺乏规范的环境下， 这种修改可能带来非常糟糕的结果——大段的代码需要重构。

桥接模式

将抽象整体与实现部分分离，使它们可以独立变化。

==> 使用组合
==> 提供setImplementor，使得具体ConcreteImplementor可以独立变化
==> 切换时重新调用setImplementor

桥接模式.png

责任链模式（Chain of Responsibility）

使多个对象都有机会处理请求，从而避免请求的发起者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，知道有一个对象处理它为止。

总体：单链表结构
设置后继节点
从头部开始索引，知道找到处理者结束请求

责任链模式.png 责任链理解图.png