设计原则
2020-07-29 10:06:55 0 举报AI智能生成
软件设计
作者其他创作
大纲/内容
LoD 迪米特法则 / 最少知识原则
Law of Demeter / Least Knowledge Principle
Law of Demeter / Least Knowledge Principle
高内聚、松耦合
高内聚：指导类本身的设计。松耦合：指导类与类之间依赖关系的设计
高内聚：相近的功能应该放到同一个类中，不相近的功能不要放到同一类中
松耦合：即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖类的代码改动
迪米特法则
概念：不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口
意义：减少类之间的耦合，让类越独立越好
DRY 原则：避免重复
Don't Repeat Yourself
Don't Repeat Yourself
概念：不要写重复的代码
3 种代码重复的情况
实现逻辑重复
功能语义重复
代码执行重复
提高代码复用性的一些手段
减少代码耦合
满足单一职责原则
模块化
业务与非业务逻辑分离
通用代码下沉
继承、多态、抽象、封装
应用模板等设计模式
有复用意识
KISS 原则：保持简单易懂
Keep It Simple & Stupid
YAGNI 原则：适可而止
You Ain't Gonna Need It
Keep It Simple & Stupid
YAGNI 原则：适可而止
You Ain't Gonna Need It
KISS 原则
概念：尽量保持简单
意义：保持代码可读和可维护的重要手段
如何写出满足 KISS 原则的代码？
不要使用同事可能不懂的技术来实现代码
不要重复造轮子，善于使用已经有的工具类库
不要过度优化
YAGNI 原则
概念：不要去设计当前用不到的功能，不要去编写当前用不到的代码
核心：不要过度设计
KISS vs YAGNI
KISS 原则：“如何做”、尽量保持简单
YAGNI 原则：“要不要做”、当前不需要的就不要做
SOLID 原则：SRP 单一职责原则
Single Responsibility Principle
Single Responsibility Principle
概念：一个类只负责完成一个职责或功能
意义
提高类的内聚性
实现代码的高内聚、松耦合
不满足的 5 种情况
1. 类中的代码行数、函数或者属性过多
2. 类依赖的其它类过多或者依赖类的其它类过多
3. 私有方法过多
4. 比较难给类起一个合适的名字
5. 类中大量的方法都集中操作类中的某几个属性
SOLID 原则：COP 开闭原则
Open-Closed Principle
Open-Closed Principle
如何理解？
开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发
同样的代码改动，在粗代码粒度下，可能被认定为“修改”；在细代码粒度下，可能又被认定为“扩展”
如何做到？
时刻具备扩展意识、抽象意识、封装意识
常用来提高代码扩展性的方法
多态
依赖注入
基于接口而非实现编程
大部分设计模式：装饰、策略、模板、职责链、状态
SOLID 原则：LSP 里氏替换原则
Liskov Substitution Principle
Liskov Substitution Principle
概念：子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏
核心：“design by contract，按照约定来设计”。父类定义了函数的“约定（或协议）”，子类可以改变函数的内部实现逻辑，但不能改变函数的原有的“约定”
里氏替换原则 vs 多态
多态是面向对象编程的一大特性，是面向对象编程语言的一种语法，是一种代码实现思路
里式替换是一种设计原则，用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑及不破坏原有程序的正确性
SOLID 原则：ISP 接口隔离原则
Interface Segregation Principle
Interface Segregation Principle
概念：客户端不应该强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者
核心：“接口”的 3 种不同的理解
1. 把“接口”理解为一组接口集合
2. 把“接口”理解为单个 API 接口或函数
3. 把“接口”理解为 OOP 中的接口
单一职责原则 vs 接口隔离原则
单一职责原则针对的是模块、类、接口的设计
接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定
SOLID 原则：DIP 依赖倒置原则
Dependence Inversion Principle
Dependence Inversion Principle
控制反转：一个比较笼统的设计思想，并不是一种具体的实现方法
依赖注入：和控制反转恰恰相反，是一种具体的编码技巧
依赖注入框架：通过依赖注入框架提供的扩展点，简单配置一下所有需要的类及其类与类之间的依赖关系，就可以实现由框架来自动创建对象、管理对象的生命周期、依赖注入等原本需要程序员来做的事情
依赖反转原则：也叫作依赖倒置原则。跟控制反转有点类似，主要用来指导框架层面的设计
0 条评论
下一页
