设计模式-6大设计原则

最新推荐文章于 2023-12-21 13:25:02 发布

Ybb_studyRecord

最新推荐文章于 2023-12-21 13:25:02 发布

阅读量158

点赞数

分类专栏：设计模式文章标签：设计模式设计原则迪米特法则单一职责原则接口隔离

本文链接：https://blog.csdn.net/m0_46690280/article/details/121124894

版权

设计模式专栏收录该内容

21 篇文章 0 订阅

订阅专栏

设计模式-6大设计原则

设计模式-6大设计原则
6大设计原则

设计模式-6大设计原则

在这里插入图片描述

6大设计原则

可维护性 Maintainability
修改功能，需要改动的地方越少，可维护性就越好
可复用性 Reusability
代码可以被以后重复使用
写出自己总结的类库
可扩展性 Extensibility/Scalability
添加功能无需修改原来代码
灵活性 flexibility/mobility/adaptability
代码接口可以灵活调用

开闭原则（Open Close Principle）

对扩展开放，对修改关闭
尽量不修改原来代码的情况下进行扩展
抽象化，多态是开闭原则的关键

当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。

开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。

开闭原则的好处是：

由于对于软件原来的模块不需要修改，因此不担心软件的稳定性。
对软件进行扩展，加入新的功能，这样，这个软件就可以通过不断地增加新模块满足不断变化的新需求。

和其他原则的关系
开闭原则具有理想主义的色彩，它是面向对象设计的终极目标

因此，针对开闭原则的实现方法，一直都有面向对象设计的大师费尽心机，研究开闭原则的实现方式。后面要提到的里氏替换原则（LSP）、依赖倒转原则（DIP）、接口隔离原则（ISP）以及抽象类（Abstract Class）、接口(Interface)等等，都可以看作是开闭原则的实现方法。

单一职责原则（Single Responsibility Principle）

就一个类而言，应该仅有一个引起它变化的原因（一个类只负责一项职责）
在这里插入图片描述

一个类别太大，别太累，负责单一的职责
Person
PersonManager
高内聚，低耦合

为什么要使用单一职责原则：
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计。

优点：

可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
提高类的可读性，提高系统的可维护性；
变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

里氏替换原则（Liskov Substitution Principle）

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格

所有使用父类的地方，必须能够透明的使用子类对象
在这里插入图片描述
里氏代换原则是对“开闭”原则的补充。实现“开闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

简单的理解为一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，软件里面，把父类都替换成它的子类，程序的行为没有变化。

但是反过来的代换却不成立，一个软件实体如果使用的是一个子类的话，那么它不能适用于其父类。

例如：

在生物学分类上，企鹅是一种鸟，但在编程世界里，企鹅却不能继承鸟。在面向对象设计时，子类拥有父类所有非private的行为和属性，鸟会飞，但企鹅不会飞，所以企鹅不能继承鸟类。

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。

依赖倒置原则（Dependence Inversion Principle）

高层模块不应该依赖低层模块，两者都应该依赖其抽象
抽象不应该依赖细节
细节应该依赖抽象

也可以说高层模块，低层模块，细节都应该依赖抽象

依赖倒转其实就是谁也不要依靠谁，除了约定的接口，大家都可以灵活自如。依赖倒转可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计了。如果设计的各个部件或类相互依赖，这样就是耦合度高，难以维护和扩展，这也就体现不出面向对象的好处了。

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

依赖倒置原则的中心思想是面向接口编程，传递依赖关系有三种方式，以上的说的都是接口传递，另外还有两种传递方式：构造方法传递和setter方法传递，相信用过Spring框架的，对依赖的传递方式一定不会陌生。

DIP的好处：采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

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

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

接口隔离原则（Interface Segregation Principle）

客户端不应该依赖它不需要的接口
类间的依赖关系应该建立在最小的接口上
每一个接口应该承担独立的角色，不干不该自己干的事情
需要对客户提供接口的时候，只需要暴露最小的接口

接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。