架构师训练营 W2 学习心得

用户头像
telliex
关注
发布于: 2020 年 06 月 17 日

SOLID

S:The Single-Responsibility Principle (SRP) / 单一职责

一个类或模块只负责完成一个职责(或者功能)。一个类或者模块包含了两个或者两个以上业务不相干的功能,我们就认为职责不够单一,应该将它拆分成多个功能更加单一、粒度更细的类或模块。拆分的维度会随业务不同阶段的需求背景而改变。重点是需要持续重构。一些参考拆分- 类中的代码行数、函数或者属性过多;最好不能超过 200 行,函数个数及属性个数都最好不要超过 10 个。- 类依赖的其他类过多,或者依赖类的其他类过多;- 私有方法过多;- 比较难给类起一个合适名字 ;- 类中大量的方法都是集中操作类中的某几个属性 ;拆分之后,如果代码的可维护性变差,就该打消念头。单一职责原则是为了实现代码高内聚、低耦合,提高代码的复用性、可读性、可维护性。

O:The Open/Closed Principle (OCP) / 开闭原则

开闭原则追求的扩展性是代码质量最重要的衡量标准之一。添加一个新的功能应该是,在已有代码基础上扩展代码(新增模块、类、方法等),而非修改已有代码(修改模块、类、方法等)。只要它没有破坏原有的代码的正常运行,没有破坏原有的单元测试,我们就可以说,这是一个合格的代码改动。开闭原则并不是说完全杜绝修改,而是以最小的修改代码的代价来完成新功能的开发。同样的代码改动,在粗代码粒度下,可能被认定为“修改”;在细代码粒度下,可能又被认定为“扩展”。需要在扩展性和可读性之间做权衡。

L:The Liskov Substitution Principle (LSP) / 里式替换原则

子类对象(object of subtype/derived class)能够替换程序(program)中父类对象(object of base/parent class)出现的任何地方,并且保证原来程序的逻辑行为(behavior)不变及正确性不被破坏。父类定义了函数的“约定”(或者叫协议),那子类可以改变函数的内部实现逻辑,但不能改变函数原有的“约定”。违反里式替换原则的例子 1. 子类违背父类声明要实现的功能 2. 子类违背父类对输入、输出、异常的约定: 子类对输入的数据的校验比父类更加严格,那子类的设计就违背了里式替换原则。 3. 子类违背父类注释中所罗列的任何特殊说明小窍门,那就是拿父类的单元测试去验证子类的代码。如果某些单元测试运行失败,就有可能说明,子类的设计实现没有完全地遵守父类的约定,子类有可能违背了里式替换原则。

I:The Interface Segregation Principle (ISP) / 接口分离原则

“接口”理解为下面三种东西:一组 API 接口集合、单个 API 接口或函数OOP 中的接口概念如果把“接口”理解为一组接口集合,可以是某个微服务的接口,也可以是某个类库的接口等。如果部分接口只被部分调用者使用,我们就需要将这部分接口隔离出来,单独给这部分调用者使用,而不强迫其他调用者也依赖这部分不会被用到的接口。如果把“接口”理解为单个 API 接口或函数,部分调用者只需要函数中的部分功能,那我们就需要把函数拆分成粒度更细的多个函数,让调用者只依赖它需要的那个细粒度函数。如果把“接口”理解为 OOP 中的接口,也可以理解为面向对象编程语言中的接口语法。那接口的设计要尽量单一,不要让接口的实现类和调用者,依赖不需要的接口函数。

接口隔离原则与单一职责原则的区别

接口隔离原则提供了一种判断接口的职责是否单一的标准:通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能,那接口的设计就不够职责单一。

D:The Dependency-Inversion Principle (DIP) / 依赖倒置原则

- 高层模块不应该依赖低层模块,两者都应该依赖其抽象;

- 抽象不应该依赖细节;

- 细节应该依赖抽象。



用户头像

telliex

关注

还未添加个人签名 2018.03.26 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营 W2 学习心得