本文共 3081 字，大约阅读时间需要 10 分钟。

软件设计的六大原则

设计模式的六大原则

参考URL: https://zhuanlan.zhihu.com/p/92152190

1. 开放-封闭原则

Open-Close Principle（OCP）：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。目的就是保证程序的扩展性好，易于维护和升级。

对于扩展是开放的，对于更改是封闭的。

开放-封闭原则是面向对象设计的核心所在, 开闭原则是Java世界里最基础的设计原则。

开闭原则被称为面向对象设计的基石，实际上，其他原则都可以看作是实现开闭原则的工具和手段。意思就是：软件对扩展应该是开放的，对修改是封闭的，通俗来说就是，开发一个软件时，应该对其进行功能扩展，而在进行这些扩展时，不需要对原来的程序进行修改。

2. 单一职责原则

Single-Responsibilitiy Principle（SRP）：对一个类而言，应该仅有一个引起它变化的原因。 如果存在多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该把多余的职责分离出去，再去创建一些类来完成每一个职责。

举个例子：一个人身兼数职，而这些事情相关性不大，甚至有冲突，那他就无法很好的解决这些问题职责，应该分到不同的人身上去做。

单一职责原则的优点

1.降低类的复杂度，一个类只负责一个职责。这样写出来的代码逻辑肯定要比负责多项职责简单得多。单一职责原则是实现高内聚低耦合的最好方法，没有之一。

2.提高类的可读性，提高系统的可维护性。

3.降低变更引起的风险。变更是必然的，如果单一职责原则遵守得好，当修改一个功能的时候可以显著降低对其他功能的影响。

需要说明的一点是，单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。比如说单一职责原则不仅仅适用于类，还适用于方法。

小结:

单一职责适用于接口，类，同时也适用于方法。

在类中新加一个方法的修改方式，虽然也违背了SRP，但在方法级别上却是符合SRP的，因为它并没有动原来方法的代码。在开发中，需要根据实际情况来确定。

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是**“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。**

但对于接口一定要做到单一职责，对于类的设计尽量做到只有一个原因引起变化。

举例

设计模式六大原则（一）：单一职责原则

参考URL: https://www.cnblogs.com/yanggb/p/10922079.html

3. 里氏替换原则

Liskov Substitution Principle：子类可以扩展父类的功能，但是不能改变父类原有的功能。

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法，父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。

保证了父类的复用性，同时也能够降低系统出错误的故障，防止误操作，同时也不会破坏继承的机制，这样继承才显得更有意义。

总结： 里氏代换原则规定子类不得重写父类的普通方法，只能重写父类的抽象方法，程序员们实际设计软件时如果非要继承的话，设计继承抽象类，而不要继承普通类。

4. 依赖倒置原则

设计模式六大原则（3）：依赖倒置原则

参考URL: https://www.cnblogs.com/ECJTUACM-873284962/p/8428172.html

Dependence Inversion Principle（DIP）：是一个类与类之间的调用规则。这里的依赖就是代码中的耦合。高层模块不应该依赖底层模块，二者都应该依赖其抽象了；抽象不依赖细节；细节应该依赖抽象、接口编程。

问题由来

类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

依赖倒置原则的核心思想是面向接口编程。

在实际编程中，我们一般需要做到如下3点：

• 低层模块尽量都要有抽象类或接口，或者两者都有。
• 变量的声明类型尽量是抽象类或接口。
• 使用继承时遵循里氏替换原则。

依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。

举例

设计模式六大原则（3）：依赖倒置原则

参考URL: https://www.cnblogs.com/ECJTUACM-873284962/p/8428172.html

5. 接口隔离原则

接口隔离原则（Interface Segregation Principle）：用于恰当的划分角色和接口，具有两种含义：1、用户不应该依赖它不需要的接口；2、类间的依赖关系应该建立在最小的的接口上。

将这两个定义概括为一句话：建立单一接口，代替庞大臃肿的接口。通俗来说就是：接口尽量细化，同时保证接口中的方法尽量的少。一个接口中包含太多的行为时，会导致它们与客户端的不正常依赖关系，要做的就是分离接口，从而实现解耦。

回到上述的单一职责原则，要求行为分离接口接口细化，感觉有些相同。但实际上，单一职责原则要求类与接口的职责单一，注重的是职责，没有要求接口尽量的少。

在接口隔离原则中，要求尽量使用多个专门的接口。专门的接口也就是提供给多个模块的接口。提供给几个模块就应该有几个接口，而不是建立一个臃肿庞大的接口，所有的模块都可以访问。

但是接口的设计是有限度的。接口的设计粒度越小系统越灵活，这是事实，但是接口太多这也就使得结构复杂，维护难度大。因此实际中，怎样把握就靠开发的经验和常识了。

6. 迪米特原则

用正反实例说说迪米特原则

参考URL: https://www.jianshu.com/p/5918a3e3f540

Law of Demeter（最小知识原则）：一个对象应该对其他对象有最少的了解。通俗来说就是，一个类对自己需要耦合或者调用的类知道的最少，你类内部怎么复杂，我不管，那是你的事，我只知道你有那么多公用的方法，我能调用。

迪米特原则核心观念就是：类间解耦，弱耦合。

从迪米特法则的定义和特点可知，它强调以下两点：

• 从依赖者的角度来说，只依赖应该依赖的对象。
• 从被依赖者的角度说，只暴露应该暴露的方法。

迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。

• 降低了类之间的耦合度，提高了模块的相对独立性。
• 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

举例

用正反实例说说迪米特原则

参考URL: https://www.jianshu.com/p/5918a3e3f540

转载地址：https://docker.blog.csdn.net/article/details/106097509 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！