软件设计原则（上）

Posted 2023-02-13 穿越临界点

在学习资料满天飞的大环境下，知识变得非常零散，体系化的知识并不多，这就导致很多人每天都努力学习到感动自己，最终却收效甚微，甚至放弃学习。我的使命就是过滤掉大量的无效信息，将知识体系化，以短平快的方式直达问题本质，把大家从大海捞针的痛苦中解脱出来。

文章目录

• • 0 引言
  • 1 SOLID设计原则
  • 2 研究对象
  • 3 指导思想
  • 4 单一职责、接口隔离、迪米特法则
  • 5 最佳实践
  • • 5.1 运用上述原则的关键
    • 5.2 可参考的设计经验
    • 5.3 编码阶段如何落地
  • 6 总结

0 引言

在《软件设计思想》中我们分析了软件设计的本质就是——分割和联系。

软件设计原则做的事情就是制定一些原则。遵守这些原则就可以比较好的做“分割和联系”这件事情。

1 SOLID设计原则

软件设计原则有很多，这里研究讨论的对象是SOLID设计原则。

Tips: S（单一职责原则）；O（开闭原则）；L（里氏替换原则）；I（接口隔离原则）；D（依赖反转原则）；D（迪米特法则/最小知识原则）。

2 研究对象

设计原则关注的两个核心是：职责 和 变化 。

两者相辅相成。职责划分的足够单一才更容易将变化与稳定进行隔离。只包含一个变化方向的类或模块才能称之为职责单一。

3 指导思想

设计原则就是针对职责和变化的约束。什么样的约束是有利于软件复用的呢？

根据我们的直觉就能想到 各司其职，变化集中。

这便是设计原则的“指导思想”。

4 单一职责、接口隔离、迪米特法则

单一职责原则约束的是一个类的责任要单一，业务角度上尽量只做一件事。不应该有两个不同的变化方向出现在同一个接口或抽象类中。我们应该将（可能的）变化点封装起来，并为这些变化点创建稳定的接口。

只做一件事并不是只有一个接口。所以，接口隔离原则约束的是对外接口内的方法暴露的要尽量少；甚至是同一个类可以根据调用者的不同设计不同的接口供给他们调用，以便让他们看到的接口中只有自己需要的方法。

Tips:注意区分接口和类的概念。一个类的声明一方面描述的类的组成，也就是职责；其中的public方法同时承担着描述接口的功能。当然，也可以把这些public方法再提取出来封装成接口抽象类，或者接口（Java中存在Interface关键字，C++中没有）。

单一职责和接口隔离约束的是一个类的设计原则；迪米特法则更关注与类与类之间的关系约束，尽量做到低耦合。它主要提倡两个类之间进行不要有任何直接关系；另外，如果一旦需要有关系，那么调用的接口越少越好（这一点和接口隔离原则刚好匹配，因为只有接口设计的足够少，调用才可能做到足够少）。

5 最佳实践

5.1 运用上述原则的关键

要精进自己业务能力，不然无法划分业务职责并提前识别变化点，因而无法设计出好的接口和类。

5.2 可参考的设计经验

除了业务上的职责划分外。可以总结一些通用的划分方法：比如属性和行为可以分离；比如数据接口和算法可以分离等等。

5.3 编码阶段如何落地

1. 模块不要过大，类不要过大，函数不要过大。

2. 对于C++来说，类中public关键字越少越好。对于C语言来说，头文件中extern越少越好。

3. 开发过程中不断重构，逐步将膨胀的类进行拆分。由粗粒度逐渐向细粒度过度，在合适的阶段过度到合适的粒度。

6 总结

本篇主要介绍了设计原则的研究对象、指导思想和非常容易搞混的三个设计原则——单一职责、接口隔离和迪米特法则。并在最后给出了落地建议。

下一篇会介绍剩余的三个设计原则。

恭喜你又坚持看完了一篇博客，又进步了一点点！如果感觉还不错就点个赞再走吧，你的点赞和关注将是我持续输出的哒哒哒动力~~