11、SOLID原则

最新推荐文章于 2024-05-09 16:36:05 发布

真理剑客

最新推荐文章于 2024-05-09 16:36:05 发布

阅读量308

点赞数

分类专栏：设计思想、原则、模式、重构

本文链接：https://blog.csdn.net/Veritas_C/article/details/104213254

版权

设计思想、原则、模式、重构专栏收录该内容

14 篇文章 1 订阅

订阅专栏

应用设计原则和设计模式，最终的目的还是提高代码的可读性、可扩展性、复用性、可维护性等，故我们在考虑应用某一个设计原则是否合理的时候，需以此作为最终的考量标准。

一、SRP-单一职责原则

一个类或者模块只负责完成一个职责(或者功能)。

通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性。
另外如果拆分的过细，则会降低内聚性，也会影响代码的可读性。对于接口，我们在设计的时候、要做到单一，但是对于实现类就需要多方面考虑。

判断类的职责是否单一

不能脱离具体的应用场景，不同的应用场景、不同阶段的需求背景、不同的业务层面视角下，对一个类是否满足单一职责原则的判断是不一样的。
开发过程中我们可以先写一个粗粒度的类，满足业务需求。随着业务发展，视具体情况拆分成几个更细粒度的类，此即持续重构。

常用的判断原则：

类的属性或函数过多、代码行数过多，如类长度不超过200行，属性不超过10个，不然影响可读性、可维护性。
依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚低耦合。
类中大量的方法都是集中操作某几个属性。
很难用一个业务名词给类起一个合适的名字。
私有方法过多，看是否可提取复用。

二、OCP-开闭原则

开闭原则是SOLID原则中最基础、最重要、最有用的一条：大多数设计模式都是为了解决代码的扩展性问题，主要遵循的就是开闭原则，开闭原则讲的就是代码的扩展性问题。

理解开闭原则：

软件实体（模块、类、方法等）应该“对扩展开发、对修改关闭”。即添加一个新的功能时，应该在已有的代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。
即以最小的修改代码的代价来完成新功能的开发，让最核心、最复杂的那部分逻辑代码满足开闭原则。

如何应用开闭原则：

1、要时刻具备扩展意识、抽象意识、封装意识；考虑未来的需求变化，设计好代码结构，留好扩展点；识别可变部分和不可变部分，隔离变化，提供抽象化的不可变接口。
2、多态、基于接口而非实现编程、依赖注入、大部分设计模式

三、LSP-里氏替换原则

子类对象能够替换程序中父类对象出现的任何地方，并且保证原来的逻辑行为不变及正确性不被破坏。

多态与里氏替换：

多态是面向对象编程的一大特性，是一种代码实现的思路，也是面向对象编程语言的一种语法。
里氏替换指导继承关系中的子类该如何设计，是一种设计原则，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。

一些违背LSP的情况：

1、子类违背父类声明要实现的功能，改变了原有程序的逻辑或破坏了原有程序的正确性。
2、子类违背父类对输入、输出、异常的约定。
3、子类违背父类注释中罗列的任何特殊说明。

四、ISP-接口隔离原则

客户端（接口的调用者或使用者）不应该被强迫依赖它不需要的接口。接口有三种理解：
一组API接口集合：如果部分接口只被部分调用者调用，那我们就将这部分接口隔离出来。
单个API接口或函数：结合具体场景，函数的功能要单一，不同的功能逻辑不要放在一个函数里。
OOP中的接口概念：如Java中的interface，那么接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数。