SOLID 原则

其实，外国人喜欢把一些重要且普遍或大力宣传让特定群体知道的东西弄成某几个单词或句子的首字母组成一个新的“词”，而这个词一般人是无法从字面上去理解，也不可能，因为它是纯粹的字母，根本没有什么特殊的意思，必须额外的脑补很多这些知识，你必须去找出它们原来是哪些单词才有可能知道它的意思。这也是汉语的神奇之处，哪怕是新词，也能通过组词把它的意思呈现出来。所以SOLID也是这样来的，SOLID如果不在软件行业里的话，真的很难知道什么是SOLID principle，它其实是软件设计的五大原则：

1. 原则1:Single Responsiblity principle 单一责任原则，说的是一个方法或一个类应该只有单一的责任。责任可以理解为变更的理由，或一种改变，我知道很多人可能会觉得就是独立的功能，但是这样其实还是很难把握的，因为功能的边界很难确定。所以我觉得理解成一种改变，只要你觉得你的代码的某部分中是要实现的功能中要完成的众多的工作中的一项，就可以把抽成一个方法或类，因为我们的目的就是让我们的方法或类成一个高内聚的单元。
2. 原则2:Open closed principle 开闭原则,就是一个类对扩展是开放的，对修改是关闭的。这一点可以通过抽象来实现。比如说你现成有一个抽象类，你想有更多扩展或者说想改变原则的一些行为，那么其实你可以实现抽象类来进行扩展，在要用到新的行为的地方用上新的实现，旧的就不会被影响到，如果旧的也要替换掉，那直接用新的，也不用改旧的实现，有时你可能会忽略一个事实，那个旧的实现可能有别人在用。所以平时的编程要围绕接口或抽象类来编程，在一要做重大行为修改时，就可以直接换实现类即可，其他都可以不用动。
3. 原则3:Liskov Substitution principle 里氏替换原则，这个原则很简单，就是所有派生类必须可以替换基类,简单点说，所以用基类声明的地方都可以用派生类的实例去赋值，这一条原则其实对开闭原则是很有帮助的，否则的话，声明的地方是一个具体的子类，那你有再多的共同的抽象基类的实现，也不可能更换掉原有的实现。
4. 原则4:Interface segregation principle 接口隔离原则，首先，接口中的方法是高内聚的，就是说接口的方法在逻辑上是应该被放在一起实现，也就是在逻辑上不应该放在接口中的，就要把它放到另外一个接口中，不应该强迫一个类去实现一个在逻辑上它不应该有的方法。比如有一个动物接口，有一个飞的方法fly()，有一个跑的方法run()。如果实现一个狗的类去实现这个接口，fly()方法在狗这个类就是不合逻辑的存在，这就违背了这一原则。应该将fly方法放到其他接口中。通过接口将这些行为隔离开，再按需要组装起来。
5. 原则5:Dependency inversion principle 依赖性倒置原则,这个原则说真的，在我了解到它之初，确实挺难理解的。很多的设计原则都是这么描述它的：高层级的模块不应该依赖低层级的模块，它们都应该依赖抽象。抽象不应该依赖具体，具体应该依赖抽象。要理解这个原则，我们要先来看什么是依赖，比如有一个类的构造器需要两个参数，那么就说这个类依赖这两个参数，否则，不能构造出这个类的实例来。要实现这一点，要利用里氏替换，这样一来高层级的，低层级的，不管它们是什么，它们的依赖都是一些抽象类或接口，那么就不会被彼此的具体的实现牵拉。抽象类或接口不应该依赖一些具体的实现，因为如果项目进行到后面，需求一变，就会因为你这个地方用了具体的类，而变得很难。就会因为修改这个具体的类，而影响了一大片。

文章来源: blog.csdn.net，作者：WongKyunban，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/weixin_40763897/article/details/124893405