《架构整洁之道》-读书笔记:7-11章
架构整洁之道: 第 7-11 章 主要讲的是 设计原则, SOLID,SOLID 的主要作用是告诉我们如何将数据和函数组织称为类,以及如何将这些类链接起来组合成一个程序.
软件构建中层模块主要目标如下:
- 使软件可容忍被改动.
- 是软件更容易被理解.
- 构建在多个系统中复用的组件.
SOLID 原则应该紧贴于代码实现之上,这些原则主要是帮助我们定义软件架构中组件和模块的.
- SRP Single Resposibility Principle
每个软件应该有且仅有一个被修改的理由. - OCP Open Close Principle
如果软件系统想要更容易被改变,那么设计就必须允许新增代码来修改系统行为,而非只能靠修改原来的代码. - LSP Liskov Substitution Principle
利用可替换的组件构建软件系统,那么这些组件就必须遵循同一个约定,以便让谢谢组件可以相互替换. - ISP Interface Segregation Principle
在设计中避免不必要的依赖. - DIP Depencency Inverse Principle
高层策略性的代码不应该依赖实现底层细节的代码,恰恰相反,那些实现底层细节的代码应该依赖高层策略性的代码.
SRP 单一职责原则
最重要的一个原则, 其他原则也基本是上都与这个原则有关.
《架构整洁之道》这本书中的例子讲的很好
任何一个软件模块都应该有且仅有一个被修改的原因.
任何一个软件模块都应该只对某一类行为者负责.
多人为了不同的目的修改了同一份源代码,这很容易造成问题的产生. 而避免这种问题产生的方法就是将服务不同行为者的代码进行切分.
OCP 开闭原则
设计良好的计算机软件应该易于扩展, 同时抗拒修改.
如果A组件不想被B组件上发生的修改所影响, 那么就应该让B组件依赖于A组件.
软件系统不应该依赖其不直接使用的组件
OCP是我们进行系统架构设计的主导原则,其主要目标是让系统易于扩展,同时限制其每次被修改所影响的范围.实现方式是通过将系统划分为一系列组件,并且将这些组件间的依赖关系按层次结构进行组织,使得高阶组件不会因低阶组件被修改而受到影响.
LSP 里氏替换原则
果对于每个类型是S的对象o1都存在一个类型为T的对象o2,能使操作T类型的程序P在用o2替换o1时行为保持不变,我们就可以将S称为T的子类型.(指导类的设计)
LSP可以且应该被应用于软件架构层面,因为一旦违背了可替换性,该系统架构就不得不为此增添大量复杂的应对机制.
ISP 接口隔离原则
任何层次的软件设计如果依赖了它并不需要的东西.就会带来意料之外的麻烦.
目的是为了解耦,不依赖其不需要的系统,避免牵一发而动全身.
DIP 依赖反转原则
如果想要设计一个灵活的系统,在源代码层次的依赖关系中就应该多引用抽象类型,而非具体实现.
在应用DIP时,我们也不必考虑稳定的操作系统或者平台设施,因为这些系统接口很少会有变动.我们主要应该关注的是软件系统内部那些会经常变动的(volatile)具体实现模块,这些模块是不停开发的,也就会经常出现变更.
稳定的抽象层
应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类. (抽象工厂)
不要在具体实现类上创建衍生类.
不要覆盖（override）包含具体实现的函数.在这里,控制依赖关系的唯一办法,就是创建一个抽象函数,然后再为该函数提供多种具体实现. (不要引入源代码层级的依赖)
应避免在代码中写入与任何具体实现相关的名字,或者是其他容易变动的事物的名字.
🏭工厂模式
如果要创建出一个稳定的抽象层, 要对那些容易变的对象的创建过程做一些特殊处理. (因为基本在所有的编程语言中,对象的创建都免不了源代码层级上依赖对象的具体实现.)
一般场景下,使用抽象工厂模式解决源代码层级依赖的问题.
中间那条曲线代表了软件架构中抽象层与具体实现层之间的边界,这里,所有跨越这条边界的源代码级别的依赖关系都应该是单向的. 也即具体实现依赖于抽象.