程序设计--设计模式六大原则

程序设计--设计模式六大原则

• 设计模式
• 设计模式六大原则
• 单一职责原则（Single Responsibility principle）
• 里氏替换原则（Liskov Substitution Principle）
• 迪米特法则（Law of Demeter）
• 依赖倒置原则（Dependence Inversion Principle）
• 接口隔离原则（Interface Segregation Principle）
• 开闭原则（Open Closed Principle）

设计模式

面向对象语言开发过程中，遇到各种场景和问题的解决方案和思路，沉淀下来就是设计模式（套路）

设计模式六大原则

面向对象语言开发过程中，推荐的一些指导性的原则（并不是强制要求的）

1. 单一职责原则（Single Responsibility principle）

• 类T负责两个不同的职责。职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
• 方法层面：也需要考虑单一职责原则，方法有多个分支或还可能发生扩展变化的，最好拆分成多个方法。从方法层次实行单一职责。
• 类层面：肯定要遵循单一职责原则，一般业务开发流程，接受输入–数据验证–逻辑计算–数据库操作–日志。这些一般都需要分层次编写。从类的层次实行单一职责。
• 类库层面：把项目拆分成多个类库，可以重用，方便维护。从类库层次实行单一职责。
• 项目层面：把系统拆分成多个项目；客户端；管理后台；定时任务；远程接口；从项目层次实行单一职责。
• 系统层次：（也可以理解为微服务）成熟的互联网企业有许多产品、项目，有很多重复的功能，比如IP库/日志库/监控系统/在线统计等等，这些功能可以用服务的形式进行提供。从系统层次实行单一职责。（服务方式 ¹ ，定时任务²）

2. 里氏替换原则（Liskov Substitution Principle）

   任何使用基类的地方，都可以透明的使用其子类；也可以理解为里氏替换原则就是继承+不改变行为

• 子类必须完全实现父类有的方法，如果子类没有父类的某项东西，就断掉继承；
• 子类可以有父类没有的东西，所以子类出现的地方，不一定能用父类来代替。
• 透明，就是安全，父类的东西换成子类后不影响程序
  a. 父类已经实现的东西，子类不要去隐藏基类的东西（子类可以用new来隐藏）
  b. 父类已经实现的东西，想改的话，就必需用virtual+override 避免埋雷

3. 迪米特法则（Law of Demeter）

   也叫最少知道原则，一个对象应该对其他对象保持最少的了解（通俗来说就是要减少依赖）。

• 高内聚，低耦合：高度封装，类与类之间减少依赖
• 耦合关系：依赖³、 关联⁴、组合⁵、聚合⁶、 继承⁷、实现⁸

• 两个名词：
  a. 直接朋友，类A和B的关系为关联或组合或聚合，那么他们就是直接朋友。
  b. 间接朋友，类A依赖B，B就是A的间接朋友。
• 迪米特法则本质为只和直接朋友通信，
• 去掉内部依赖------降低访问修饰符
• 门面模式（也叫外观模式）遵循的就是迪米特法则，举个例子：
  一个客户端执行订单操作，它需要生成订单-----操作库存-----操作钱库-------写日志，等一系类操作。虽然这些操作都是客户端的直接朋友，但是客户端直接操作这些朋友明显是不好的。这时就需要在封装一层门面类来操作这些朋友，客户端操作门面类。
• 中介者模式，也是用的迪米特法则。举个例子：
  服务A、B、C、D、E、F，两两之间都有可能进行通信，那么A就有BCDEF五个直接朋友，同理每个服务都有五个朋友，这样就造成了依赖混乱。中介者模式就是起一个中介者的服务G，G有ABCDEF六个朋友，由G负责中转通信。这样G的依赖度上升，但ABCDEF的依赖都降低了，这就是中介者模式。

4. 依赖倒置原则（Dependence Inversion Principle）

   高层模块不应该依赖与底层模块，二者应该通过抽象依赖。

• 依赖抽象⁹而不是依赖细节。
• 也就是面向抽象编程，底层模块里面尽量都有抽象类/接口；在声明参数、变量、属性的时候，尽量的都是接口/抽象类。
• 依赖细节：程序写死了，不谈什么扩展。
• 依赖抽象，更具有通用性；而且具备扩展性；
• 细节是多变的，抽象是稳定的；
• 系统架构基于抽象来搭建，会更稳定，更具备扩展性。
• 扩展技巧：建议接口和实现分开生成DLL。

5. 接口隔离原则（Interface Segregation Principle）

   客户端不应该依赖它不需要的接口；

• 一个类对另一个类的依赖应该建立在最小的接口上；
• 实现一个接口的时候，只需要自己必须的功能；
• 通俗来说就是，一个接口可以代表多个功能（但不包括实现）；但是接口隔离原则建议一个接口只代表一个功能或一个单位的功能。
• 用到哪个功能就实现哪个接口。
• 接口隔离原则不建议，建立一个功能大而全的接口；原则建议拆分功能。

6. 开闭原则（Open Closed Principle）

   对扩展开放，对修改关闭

• 如果有对功能扩展变化的需求，希望是增加类而不是修改
• 修改可能会影响原有的功能，引入错误；增加类就不会影响原有的东西。
• 原则的原则，五大原则是手段，这个是目标。
• 扩展功能时，从影响最大的做法-------->影响最小的做法：
  修改方法–>增加方法（修改类） -->增加类 --> 增加dll -->修改配置文件

---

1. 服务不仅可以放在iis上，也可以做成windows服务。 ↩︎

2. 定时任务可以放在iis上，也可以用window计划任务，还可以用quartz控制台。 ↩︎

3. 依赖,一个类B仅仅只出现在另一个类A的方法中,那么就说A依赖B。 ↩︎

4. 关联, 比如student类中有一个grade类，那么student和grade类就有关联关系。 ↩︎

5. 组合，比如people类由head类、body类、hand类组成，这就是组合关系。 ↩︎

6. 聚合，和组合关系差不多。 ↩︎

7. 继承，说的是子类和父类的关系。 ↩︎

8. 实现，说的是类与接口的关系。 ↩︎

9. 依赖抽象也就是使用抽象类或接口来代替实现类。 ↩︎

来源：CSDN

作者：Core松

链接：https://blog.csdn.net/qq_41807126/article/details/104086864