23种设计模式之基本介绍

最新推荐文章于 2024-08-18 21:36:31 发布

你好，琦

最新推荐文章于 2024-08-18 21:36:31 发布

阅读量394

点赞数

分类专栏：设计模式文章标签： java 设计模式面试编程语言

本文链接：https://blog.csdn.net/space_qi/article/details/111209665

版权

设计模式专栏收录该内容

24 篇文章 0 订阅

订阅专栏

23种设计模式之基本介绍

文章目录

23种设计模式之基本介绍

参考资料

下文如有错漏之处，敬请指正

一、简介

设计模式（Design Pattern）是一套理论，是软件界前辈们代码设计经验的总结，其目的是为了提高代码的可扩展性、可靠性、可重用性和可读性。

使用设计模式，可以使软件具有：

可扩展性（可以非常方便的增加新的功能）
可靠性（当增加新功能后，对原有的功能不产生影响）
可重用性（相同功能的代码，不用多次编写）
可读性（编程规范，便于其他程序员的阅读和理解）

设计模式常用的7大原则：

单一职责原则（Single Responsibility Principle）
接口隔离原则（Interface Segregation Principle）
依赖倒转原则（Dependence Inversion Principle）
里氏替换原则（Liskov Substitution Principle）
开闭原则（Open/Closed Principle）
迪米特原则（Least Knowledge Principe）
合成复用原则（Composite Reuse Principle）

二、7大原则

单一职责原则（SRP）

基本介绍

一个类、接口、或方法只负责一项职责，即只做一件事
目的是降低类的复杂度，使每一个类、接口或方法都有一个清晰的定义

场景模拟

如类A负责两个不同的职责：职责1，职责2。当职责1的需求变更而要修改类A时，可能造成职责2执行错误，所以需要将类A的粒度分解为类A1（包含职责1）和类 A2（包含职责2）。

接口隔离原则（ISP）

基本介绍

一个类对另一个类的依赖应该建立在最小的接口上，即一个类不应该依赖它不需要的接口。

场景模拟

一个接口I有5个功能，类A实现了该接口I，但实际只用到接口I的2个功能，这时类中的另外三个方法就会被浪费，所以需要将接口I的粒度进行分解，将类A需要的两个接口分离出来变为接口X，让类A实现接口X，使类A中的功能全部被使用。

依赖倒转原则（DIP）

基本介绍

高层模块不应该依赖低层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
依赖倒转的中心思想是面向接口编程
目的是减少类间的耦合性，提高系统的稳定性

场景模拟

每个APP都有页面显示的需求，且每个APP页面显示的内容均不同，手机系统不可能为每个APP页面显示单独开发。因此手机系统自定义一个页面显示功能接口，对显示功能进行规范，让每个APP实现该接口进行页面显示的定制开发。

里氏替换原则（LSP）

基本介绍

父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常
里氏替换原则是对继承（OO）的规范
如果父类的某些方法在子类中发生了”畸变“（改变了方法原有的意义），建议断开继承关系，采用依赖、聚合或组合的方式代替继承
子类可以扩展父类的功能，但不能改变父类原有的功能，即子类中尽量不要重写父类的方法
目的是代码共享，减少创建类的工作量和提高代码的可扩展性

场景模式

如一个动物类，其中有一个方法是奔跑。老虎类继承了动物类，老鹰也继承了动物类，但是它不会奔跑，于是它重写了父类的奔跑方法，此时便违反了里氏替换原则。因此要对动物类进行粒度分解，分为飞禽类和走兽类，让老鹰继承飞禽类。

开闭原则（OCP）

基本介绍

一个软件的实体应该对扩展开放，对修改关闭。即一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。
用抽象构建框架，用实现扩展细节

场景模拟

如有一个主题类，当用户想更换主题时，需要对原有主题类的代码进行更改，这就违反了开闭原则。所以应将主题类设为抽象类，由其子类来定义主题，当需要更换主题时，只要增加一个子类，不改变原有代码结构。

迪米特原则（LKP）

基本介绍

迪米特原则又称为最少知识原则
从依赖者的角度来说，只依赖应该依赖的对象。
从被依赖者的角度说，只暴露应该暴露的方法。

场景模拟

如电影制作公司，当电影制作完成之后交由院线上线，由院线排片出售票务，由院线和用户产生关系，电影制作公司不与用户产生关系。

合成复用原则（CRP）

基本介绍

尽量使用组合或聚合的方式替代继承。

场景模拟

如咖啡店出售的咖啡可以搭配调料，调料有（牛奶，芝士，方糖），如果使用继承的话，就会有一个咖啡父类，咖啡+牛奶类、咖啡+芝士类、咖啡+方糖，每当增加一个调料时，就要增加一个咖啡类+调料类，如果调料非常多，那么将会产生非常多的类。此时可以采用组合或聚合的方法，有一个咖啡父类，在咖啡父类中聚合调料对象，在使用时只需要将调料传入，每当增加一个调料，只需要将调解对象传入，不需要增加新的咖啡类。

7种原则总结

每种原则要求的侧重点不同。
开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭。
里氏替换原则告诉我们不要破坏继承体系。
依赖倒置原则告诉我们要面向接口编程。
单一职责原则告诉我们实现类要职责单一。
接口隔离原则告诉我们在设计接口的时候要精简单一。
迪米特法则告诉我们要降低耦合度。
合成复用原则告诉我们要优先使用组合或者聚合关系，少用继承关系。

三、类与类之间的关系

依赖（虚线箭头）
- 一个类在类中使用到另一个类，则两个类之间存在依赖关系。
- 在UML类图中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方
- 如下图所示，Person类依赖Address类
泛化（实线空心）
- 泛化实际上是继承关系
- 在UML中，泛化关系用带空心三角形的直线来表示，由子类指向父类
- 如下图所示，Student与Professor是子类，Person是父类
实现（虚线空心）
- 实现实际上是面向接口编程
- 在UML中，实现关系用带空心三角形的虚线来表示，由接口实现类指向接口类
- 如下图所示，Diesel与NEV是接口实现类，Vehicle是接口类
关联（实线）
- 描述类之类间的关系。
  - 单向
    - 1:1
    - 1:n
    - n:1
  - 双向
    - 1:1
    - 1:n
    - n:m
- 在UML中，关联关系用实线来表示
- 如下图所示，Person类与Address的关联关系是（1:n）
聚合（空心菱形）
- 整体和部分的关系且整体与部分可以分离，即has-a的关系。
```
public class Car{
private MusicSystem musicSystem; //聚合关系
}
```
- 在UML中，聚合关系使用空心菱形表示（菱形指向的是整体），由部分指向整体
- 如下图所示，Car类聚合MusicSystem类
组合（实心菱形）
- 整体和部分的关系且整体与部分不可以分离，即contains-a的关系。
```
public class Car{
 private Engine=new Engine();	//组合关系
}
```
- 在UML中，组合关系使用实心菱形表示（菱形指向的是整体），由部分指向整体
- 如下图所示，Car类组合Engine类