【学习笔记】设计模式的七大原则

设计模式的目的

• 代码的重用性 （相同功能的代码不用重复编写）
• 可读性 （便于其他程序员阅读和理解）
• 可拓展性 （便于添加新功能，也成为可维护性）
• 可靠性 （增加新功能后，对原功能无影响）
• 使程序呈现高内聚，低耦合。

七大原则

单一职责原则

对于一个类来说，一个类应该值负责一项职责。
即 降低类的复杂度，一个类只负责一项职责（非一个方法）。

接口隔离原则

客户端不应该依赖它不需要的接口。
即一个类对另一个类的依赖应建立在最小接口上，可以见一个接口拆分成多个接口，在自由组合。

依赖倒转原则

• 高模块不应该依赖低模块，两者都应该依赖其抽象。
• 抽象不应该依赖细节，细节应该依赖抽象。
• 依赖倒转的核心是面向接口编程。
• 抽象 是指 接口或者抽象类，细节指具体的实现类。
• 实现方法（依赖关系的传递）
  接口传递，构造方法传递，setter 传递

里氏替换原则

继承的好与坏
继承给程序设计带来便利的同时，也带来了弊端。比如继承给程序带来了侵入性，程序的可移植性低，增加了对象间的耦合性。
对父类修改时，必须考虑到所有的子类，并且父类的修改后，所有涉及到的子类的功能都可能出错。

里氏替换原则：指导如何使用继承。
继承实际上让两个类的耦合性增加了，在适当的情况下，可以通过 聚合， 组合， 依赖 来解决问题。

开闭原则 （最基础，最重要的原则）

• 一个软件实体如类，模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。
• 用抽象构建框架，用实现扩展细节。
• 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是修改已有的代码来实现变化。
  使用设计模式的目的就是遵循开闭原则。

迪米特原则

目的： 降低类之间的耦合。

• 一个类应该对其他对象保持最少的了解。
• 类与类的关系越密切，耦合度越大。
• 迪米特原则，也称为 最少知道原则
  • 一个类的对自己依赖的类知道的越少越好。
  • 对于被依赖的类，不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供public方法，不泄露任何细节信息。
• 也称为 只与直接朋友通信
  • 每个对象都会与其他对象有耦合关系，只要两个对象有耦合关系，我们就说这两个对象之间时朋友关系。
  • 耦合的方式：依赖，关联，组合，聚合。
  • 称出现在成员变量，方法参数，方法返回值中的类 为直接朋友。
  • 而出现在局部变量中的类不是直接朋友。
  • 即：陌生的类最好不要以局部变量的形式出现在类内部。

合成复用原则

尽量使用合成/聚合 的方式，少使用继承。

UML 类图

UML图的分类

• 用例图
• 静态结构图 ：类图，对象图，包图，组件图，部署图
• 动态结构图 ：交互图（时序图与协作图），状态图，活动图

类图

• 用于描述系统中的类（对象）本身的组成和类（对象）之间的各种静态关系
• 类之间的关系
  • 依赖
  • 泛化（继承）
  • 实现
  • 关联
  • 聚合
  • 组合

依赖关系 Dependence

只要类中用到了对方，那么他们之间就存在依赖关系

• 类中用到了对方
• 类的成员属性
• 方法的返回类型
• 接收的参数类型
• 方法中使用到

泛化关系 Generalization

泛化关系实际上就是继承关系，它是依赖关系的特例

实现关系 Implementation

实现关系就是A类实现B接口，也是依赖关系的特例

关联关系 Association

• 关联关系实际上就是类与类之间的关系，是依赖关系的特例
• 具有导航性，即双向关系或单向关系
• 关系具有多重性

聚合关系 Aggregation

聚合关系表示的是整体和部分的关系，整体和部分可以分开

• 导航性
• 多重性

组合关系 Composition

聚合关系表示的是整体和部分的关系，整体和部分不可以分开
人和head是组合关系，人和 IDCard 是聚合关系