【设计模式】基础概述

逆羽飘扬

已于 2023-11-15 10:39:00 修改

阅读量351

点赞数

分类专栏： # 面试经验文章标签：设计模式开发语言

于 2023-02-17 09:48:49 首次发布

本文链接：https://blog.csdn.net/qq_43840665/article/details/129078321

版权

面试经验专栏收录该内容

19 篇文章 0 订阅

订阅专栏

设计模式概述

在这里插入图片描述

文章目录

会更新每种模式的详细博客超链接，敬请期待呀
- 参考博客

😊点此到文末惊喜↩︎

一、设计模式

1. 基本简介

定义：设计模式是一个针对重复发生的问题的解决方案，可以降低耦合
核心目标：在解决问题过程中，封装变化，重用不变
模式的基本要素
- 模式名：是一个助记词，方便与其他人交流和形成规范的工程文档
- 问题：通过前因后果选择相应的设计模式
- 解决方案：设计模式在具体应用场景的特化
- 效果：通常考虑的是软件的拓展性、复用性和封装性
两个项目思维方式
- 抽象思维：自低向上，通过不断抽象降低项目复杂度
  - 面向对象
  - 组件封装
  - 设计模式
  - 架构设计
- 底层思维：自顶向下，从机器运行角度把握对象构造
  - 语言转换
  - 编译转换
  - 内存模型
  - 运行时机制
面向对象的三大机制
- 封装：隐藏内部实现
- 继承：复用现有代码
- 多态：改写对象行为
软件领域的复杂性的根本原因是：需求的变化
解决复杂性的方式
- 分解：从不同维度，将复杂问题进行划分成多个简单问题（每个维度都是一种分解方法，评判标准是可复用性）
- 重构：先构造基本模型，然后寻找问题，找到最好的解决这个问题的设计模式
- 抽象：忽略非本质细节，降低复杂性。尽量进行统一处理，复用代码
- 封装：寻找变化点，然后在变化点处应用设计模式，封装变化
模式分类
- 创建型模式Creational：将对象的部分创建工作进行封装，从而避免需求变化对对象创建的冲击
- 结构型模式Structural：通过类的继承或对象的组合，从而应对需求变化对对象结构带来的冲击
- 行为型模式Behavioral：通过类的继承或对象的组合来划分不同类之间的职责，从而应对需求变化为多个交互对象造成的冲击
重构的常用方式
- 静态转化成动态
- 早绑定转化成晚绑定
- 继承转化成组合
- 编译时依赖转化成运行时依赖
- 紧耦合转化成松耦合
思考类的设计模式，要看其中的稳定和变化的部分
代码的复用性是指编译形成的二进制意义上的相同，通常是编译时代码复用，执行时动态链接
复制粘贴是最容易的编程，但是也容易造成重复和耦合。

2. 面向对象设计原则

面向对象设计的原则
- 隔离变化：通过抽象将变化带来的影响减为最小
- 各司其职：接口相同，通过多态实现不同，各负其责
设计原则：首字母缩写SOLID（稳定的）
- 单一职责原则（Single Responsibility Principle）
  - 一个类应该只有一个引起它变化的原因，职责的耦合会减弱类完成其他功能的能力
  - 变化的方向隐含类的责任
- 开放封闭原则（Open Closed Principle）
  - 对拓展开放，对更改封闭。即模块（类、函数···）可拓展但不可修改源代码
  - 使用拓展的方式应对变化
  - 通过抽象隔离同类变化
- 里氏替换原则（Liskov Substitution Principle）
  - 子类必须能够替换它们的父类，即子类具有父类的所有属性
  - 继承表达类型抽象
- 最少知道法则（Law of Demeter）
  - 每个类都应该尽可能的减少对其他类的依赖，交流通过友元类进行
  - 可能造成系统中出现大量传递类调用关系的友元类
- 接口隔离原则（Interface Segregation Principle）
  - 尽量减少用户对于接口方法的依赖，避免接口更改引起的问题
- 依赖倒置原则DIP（Dependence Inversion Principle）
  - 底层继承接口（抽象类）进行实现，接口通过组合的方式被高层模块调用
  - 稳定的高层模块不应该依赖于易变化的底层模块，而都应该依赖于稳定的抽象
  - 稳定的抽象不应该依赖于易变化的实现细节，细节应该依赖抽象
- 优先使用对象组合，而不是类继承
  - 继承某种程度上破坏了封装性，子类和父类耦合度高
  - 被组合的对象必须具有良好定义的接口
- 封装变化点
  - 变化点是指一侧变化，一侧稳定。变化一侧的修改不会影响稳定一侧
- 面向接口编程，而不是实现
  - 客户程序无需获知对象的具体类型，只需要知道对象的接口