设计模式: 面向对象思想，软件设计原则与设计模式之间的关系

关注

原创 2024-03-27 17:30:36 450 阅读 AI 写同款· GEO 优化 ›

探索设计模式的魅力：深入理解面向对象设计的深层原则与思维 软件设计原则是指在软件开发过程中，通过一系列指导性的原则来指导设计决策和编码实践。这些原则旨在提高软件系统的质量，使其具有可维护性、可扩展性、可重用性和可测试性。几个重要性：可维护性、可扩展性、可重用性、可测试性和降低系统复杂度。软件设计原则是提高软件系统质量和可维护性的基石。遵循这些原则可以使得代码更加清晰、灵活和可靠，提高开发效率和软件质量，减少后期维护成本。同时，它们也为团队合作和团队成员共同理解代码提供了共同的规范和指导。阅读详情

面向对象

我们知道一般编程思想有：面向过程，面向对象，面向切面编程，在软件开发中比重最大的就是面向对象编程了
在面向对象中有一个"类"的概念，其实它就是模板
面向对象的三要素：继承封装多态
- 继承：子类继承父类(公共类)
- 封装: 数据的权限和保密, public, protected, private, 减少耦合，保护特定数据, 数据,接口的权限管理, ES6中不支持, _开头的属性是private
- 多态: 同一接口不同实现, 比如ts中的重写和重载, 保持子类开放性和灵活性，面向接口编程
拿js应用来举例
- jQuery是一个class
- $(‘p’)是jQuery的一个实例
为何使用面向对象
- 程序执行：顺序，判断，循环 - 结构化
- 面向对象 - 数据结构化，对于计算机，结构化才是最简单的
- 编程应该简单 & 抽象
面向对象是一种思想，实现面向对象需要用到设计模式

软件设计中的设计与设计哲学

1 ）何为设计？

描述：按照一种思路或标准来实现功能
结合《UNIX/LINUX设计哲学》
功能相同，可以有不同设计方案来实现
伴随需求增加, 设计的作用才能体现出来

2 ） UNIX/LINUX设计哲学

准则1: 小即美
准则2: 让每个程序只做好一件事
准则3: 快速建立原型
准则4: 舍弃高效率而取可移植性(通用)
准则5: 采用纯文本来存储数据(方便人读，可读性)
准则6: 充分利用软件的杠杆效应(软件复用)
准则7: 使用shell脚本来提高杠杆效应和可移植性
准则8: 避免强制性的用户界面
准则9: 让每个程序都称为过滤器
小准则: 允许用户定制环境
小准则: 尽量使操作系统内核小而轻量化
小准则: 使用小写字母并尽量简短
小准则: 沉默是金，比如输出数字，有缺省值-1，而非字符串
小准则: 各部分之和大于整体，以小的个体组成大的整体
小准则: 寻求90%的解决方案，产品面向用户不可能满足100%用户，只需要90%即可

3 ）演示：沉默是金+每个程序成为过滤器

ls
ls | grep *.json
ls | grep *.json | grep 'package' # 这里可能输出 package.json
ls | grep *.json | grep 'package1' # 这里啥都没输出
ls | grep *.json | grep 'package' | wc -l # 这里是0
ls | grep *.json | grep 'package1' | wc -l # 如果在 ls | grep *.json | grep 'package1' 输出结果为字符串no files, 这里就是1了

4 ） SOLID 5大设计原则

S 单一职责原则
O 开放封闭原则
L 里氏置换原则
I 接口独立原则
D 依赖倒置原则：编程要依赖接口而非具体实现

4.1） S原则（单一职责原则）

永远都不应该有多于一个原因来改变某个类
对于一个类而言，应该仅有一个引起它变化的原因
如果一个类拥有了两种职责，那就可以将这个类分成两个类
如登录验证：验证用户名和密码，应该分开写两个方法
一个程序只做好一件事
如果功能过于复杂就拆分开，每个部分保持独立

4.2） O原则（开放封闭原则）

对扩展开放，对修改封闭
封装的类应该便于扩展，但不要去修改类
增加或改动需求时，扩展新代码，而非修改已有代码，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码
这是软件设计终极目标
举例：
- 需要修改已有代码，成本非常之高，对测试人员巨大的压力
- 多人开发，多个需求，需要修改已有代码，会有很多冲突问题

4.3） L原则（里氏置换原则）

父类在使用的过程中，一定能够被子类替换或覆盖
- 在使用方法的时候，如果将父类的引用，换为子类的引用，对整体程序设计来说是没有任何影响的
- 在面向对象中会出场率很高：比如继承和多态
- 但是在前端函数式编程中，出场率和关注度并不高

父类能出现的地方子类就能出现
js中使用较少(弱类型 & 继承使用较少)

4.4） I原则（接口独立原则）

一个类与另一个类的关联，应尽量依赖于尽可能小的接口
- 不需要对外暴露，没有实际意义的接口，用户不应该依赖它不需要的接口
- 当对外暴露接口时，如果一个接口是非必要的，应该删除，不应该存在

保持接口的单一独立, 避免出现 “胖接口”，尽量不要出现一个函数能解决很多问题，但不是100%不能出现
js中没有接口(ts中例外)，使用较少
类似于单一职责原则，这里更关注接口(函数或方法)

4.5） D原则（依赖倒置原则）

高层模块不应该依赖于底层模块，他们应该依赖于抽象
抽象不应该依赖细节，细节应该依赖抽象
应该面向接口编程，不应该面向实现类编程
接口中限定了一部分类型，实现类在实现的时候，接口中所有的方法和属性都需要用到
实现类中有一些自己实现的方法，是不确定的，不需要关注这部分的实现
不是说所有类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口编程
面向接口编程，依赖于抽象而不依赖于具体
使用方只关注接口而不关注具体类的实现
JS中使用较少，没有接口 & 弱类型，但是TS弥补了这个缺陷

5 ) 用前端中的Promise来说明SO

function loadImg(src) {
    return new Promise((resolve, reject)=>{
        var img = document.createElement('img')
        img.onload = function() {
            resolve(img)
        }
        img.onerror = function() {
            reject('图片加载失败')
        }
        img.src = src
    })
}

var src = 'http://www.xxx.com/x.png'
loadImg(src)
.then((img)=>{
    return img
})
.then((img)=>{
    console.log('img.height', img.height)
}).catch((ex)=>{
    // 统一捕获异常
    console.log(ex)
})

单一职责体现，每个then只做一件事，如果想做另一件事，需要添加一个新的then
开放封闭体现，如果有新需求，只需要添加新的then即可
真正应用时候可通过模块化将各个逻辑拆分到不同文件中

6 ）补充原则

最少知识原则
- 只与你最直接的对象交流
- 这里最直接的对象是指与自己有直接关联的对象
- 可以用一句话总结，就是高内聚和低耦合：将我们的代码和其他有联系的代码进行最少的关联, 在做系统设计的时候，尽量减少依赖关系
组合/聚合复用原则
- 日常程序设计的时候，当扩展类功能时，应优先考虑组合，而非继承，组合优于继承
  - 组合的灵活性比继承的要大很多
  - 此原则在23种设计模式中频繁使用，如代理，装饰，适配器模式
无环依赖原则
- 如果A模块依赖B,B依赖C,C依赖A 此时构成循环依赖
- 应避免出现此种设计，如果出现这种情况，应该使用中介者模式来解决
共同封装原则
- 应该将易变的类放在同一个包中，将变化隔离出来
- 该原则是基于开放封闭原则中诞生的一个原则
共用重用原则
- 如果重用了包中的一个类，那也就相当于重用了包中的所有类，也就是父类，基类
- 我们要尽可能减少包的大小
依赖注入原则
- 又名好莱坞原则：Don’t call me, I’ll call you.
- 也称为控制反转原则
- 不需要主动创建对象，而是由容器帮我们来创建并管理这些对象
- 比如require或import引入的模块，就是依赖注入
其他设计原则
- 不重复原则：不要让重复代码到处都是，要让他们足够重用，所以进可能地封装
- 保持它简单与傻瓜
  - 保持系统界面简洁，功能实用，操作方便
  - 入参和出参不应该太多，了解其作用和副作用
- 高内聚，低耦合
  - 模块内部需要做到高内聚，模块之间要做到低耦合
- 关注点分离
  - 将一个复杂问题，分解为多个简单问题，逐一解决
  - 也就是分而治之，如何进行分离是关键
- 你不需要它
  - 完美架构设计者：设计一种程序可包容所有错误，可更好应对更好发展，做了大量适配所有应用的代码，付出远大于收益
  - 不要一开始就把系统设计的非常复杂，不要陷入过度设计的深渊
  - 应该让系统开开始的时候，设计足够简单，但又不失扩展性