设计模式的目的
- 代码的重用性 (相同功能的代码不用重复编写)
- 可读性 (便于其他程序员阅读和理解)
- 可拓展性 (便于添加新功能,也成为可维护性)
- 可靠性 (增加新功能后,对原功能无影响)
- 使程序呈现高内聚,低耦合。
七大原则
单一职责原则
对于一个类来说,一个类应该值负责一项职责。
即 降低类的复杂度,一个类只负责一项职责(非一个方法)。
接口隔离原则
客户端不应该依赖它不需要的接口。
即一个类对另一个类的依赖应建立在最小接口上,可以见一个接口拆分成多个接口,在自由组合。
依赖倒转原则
- 高模块不应该依赖低模块,两者都应该依赖其抽象。
- 抽象不应该依赖细节,细节应该依赖抽象。
- 依赖倒转的核心是面向接口编程。
- 抽象 是指 接口或者抽象类,细节指具体的实现类。
- 实现方法(依赖关系的传递)
接口传递,构造方法传递,setter 传递
里氏替换原则
继承的好与坏
继承给程序设计带来便利的同时,也带来了弊端。比如继承给程序带来了侵入性,程序的可移植性低,增加了对象间的耦合性。
对父类修改时,必须考虑到所有的子类,并且父类的修改后,所有涉及到的子类的功能都可能出错。
里氏替换原则:指导如何使用继承。
继承实际上让两个类的耦合性增加了,在适当的情况下,可以通过 聚合, 组合, 依赖 来解决问题。
开闭原则 (最基础,最重要的原则)
- 一个软件实体如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方)。
- 用抽象构建框架,用实现扩展细节。
- 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是修改已有的代码来实现变化。
使用设计模式的目的就是遵循开闭原则。
迪米特原则
目的: 降低类之间的耦合。
- 一个类应该对其他对象保持最少的了解。
- 类与类的关系越密切,耦合度越大。
- 迪米特原则,也称为 最少知道原则
- 一个类的对自己依赖的类知道的越少越好。
- 对于被依赖的类,不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供public方法,不泄露任何细节信息。
- 也称为 只与直接朋友通信
- 每个对象都会与其他对象有耦合关系,只要两个对象有耦合关系,我们就说这两个对象之间时朋友关系。
- 耦合的方式:依赖,关联,组合,聚合。
- 称出现在成员变量,方法参数,方法返回值中的类 为直接朋友。
- 而出现在局部变量中的类不是直接朋友。
- 即:陌生的类最好不要以局部变量的形式出现在类内部。
合成复用原则
尽量使用合成/聚合 的方式,少使用继承。
UML 类图
UML图的分类
- 用例图
- 静态结构图 :类图,对象图,包图,组件图,部署图
- 动态结构图 :交互图(时序图与协作图),状态图,活动图
类图
- 用于描述系统中的类(对象)本身的组成和类(对象)之间的各种静态关系
- 类之间的关系
- 依赖
- 泛化(继承)
- 实现
- 关联
- 聚合
- 组合
依赖关系 Dependence
只要类中用到了对方,那么他们之间就存在依赖关系
- 类中用到了对方
- 类的成员属性
- 方法的返回类型
- 接收的参数类型
- 方法中使用到
泛化关系 Generalization
泛化关系实际上就是继承关系,它是依赖关系的特例
实现关系 Implementation
实现关系就是A类实现B接口,也是依赖关系的特例
关联关系 Association
- 关联关系实际上就是类与类之间的关系,是依赖关系的特例
- 具有导航性,即双向关系或单向关系
- 关系具有多重性
聚合关系 Aggregation
聚合关系表示的是整体和部分的关系,整体和部分可以分开
- 导航性
- 多重性
组合关系 Composition
聚合关系表示的是整体和部分的关系,整体和部分不可以分开
人和head是组合关系,人和 IDCard 是聚合关系