设计模式七大原则

1. 设计模式简介

使用设计模式是为了让程序具有更好的代码重用性、可读性、可扩展性、可靠性，使程序呈现高内聚、低耦合的特性

设计模式分类：

1. 创建型模式：
   1. 单例模式(Singleton)
   2. 工厂方法模式(Factory Method)
   3. 抽象工厂模式(Abstract Factory)
   4. 原型模式(Prototype)
   5. 建造者模式(Builder)
2. 结构型模式：
   1. 适配器模式(Adapter)
   2. 桥接模式(Bridge)
   3. 装饰模式(Decorator)
   4. 组合模式(Composite)
   5. 外观模式(Facade)
   6. 享元模式(Flyweight)
   7. 代理模式(Proxy)
3. 行为型模式：
   1. 模板方法模式(Template Method)
   2. 命令模式(Command)
   3. 访问者模式(Visitor)
   4. 迭代器模式(Iterator)
   5. 观察者模式(Observer)
   6. 中介者模式(Mediator)
   7. 备忘录模式(Memento)
   8. 解释器模式(Interpreter)
   9. 状态模式(State)
   10. 策略模式(Strategy)
   11. 责任链模式(Chain Of Responsibility)

类图显示了类与类的关系：

1. 依赖关系(Dependency)：在一个类中用到了另一个类，那么它们之间就存在依赖关系；依赖关系表现为函数中的参数(use a)
2. 一般化关系：表示为类与类之间的继承关系(Inheritance)，接口与接口之间的继承，类对接口的实现关系(Realization)；一般化关系表现为继承或实现关系(is a)
3. 关联关系(Association)：类与类之间的联系，它使一个类知道另一个类的属性和方法；关联具有导航性(单/双向关系)和多重性(m对n关系)；关联关系表现为变量(has a)
4. 聚合关系(Aggregation)：是强的关联关系。聚合关系是整体和个体的关系。聚合关系两个类处于不同的层次，一个是整体，一个是部分，整体与部分可以分开
5. 复合关系(Composition)：是比聚合关系强的关联关系。它要求代表整体的对象负责代表部分的对象的生命周期，整体与部分不可以分开

设计模式之间的关系：

2. 设计模式七大原则

2.1 单一职责原则

单一职责原则：一个类应该只有一个职责(类变化的原因)

1. 只有逻辑足够简单时，才可以在代码级别违反单一职责原则
2. 只有类中方法数量足够少时，才可以在方法级别保持单一职责原则
3. 单一职责原则降低了类的复杂度和变更引起的风险

2.2 接口隔离原则

接口隔离原则：接口要小而专，绝不能大而全

1. 使用多个专门的接口比使用单一的总接口要好
2. 一个类对另外一个类的依赖性应当是建立在最小的接口上的
3. 一个接口代表一个角色(能力、约定)，不应当将不同的角色都交给一个接口
4. 不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变

2.3 依赖倒转原则

依赖倒转原则：面向接口编程

1. 程序要依赖于抽象接口，不要依赖于具体实现
2. 高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象
3. 抽象不应该依赖于具体，具体应该依赖于抽象

2.4 里氏代换原则

里氏代换原则：能用父类型的地方就一定能使用子类型

1. 在进行设计的时候，尽量从抽象类继承，而不是从具体类继承
2. 子类尽量不要重写父类的方法；若需要重写，则考虑让原来的父类和子类都继承一个更通俗的基类，采用依赖、聚合、组合等关系代替原有的继承关系

里氏替换原则可以检查继承关系是否合理，如果一个继承关系违背了里氏替换原则，那么这个继承关系一定是错误的，需要对代码进行重构

2.5 开闭原则

开闭原则：软件中的对象应该对扩展开放，对修改封闭

2.6 迪米特法则(最小知识原则)

迪米特法则(最小知识原则，LOD)：一个类对于其他类知道的越少越好，只和朋友通信

出现在成员变量、方法参数、方法返回值中的类为朋友；而出现在局部变量中的类不是朋友

迪米特法则不希望类之间建立直接的联系，因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系，这在一定程度上增加了系统的复杂度

外观模式和中介者模式实际上就是迪米特法则的应用

2.7 合成复用原则

合成复用原则：优先使用聚合或复合关系来复用代码，而不是使用继承