【学习笔记】【Datawhale12月】大话设计模式 - 设计准则

39 阅读 0 评论 26 点赞

我是靠谱客的博主能干小虾米，最近开发中收集的这篇文章主要介绍【学习笔记】【Datawhale12月】大话设计模式 - 设计准则，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

参考：
Datawhale12月组队学习
设计概念和七大准则-腾讯云

学习心得总结

本阶段是引入设计模式的概念以及七大设计原则。设计模式和我之前学习的算法非常不同，“是针对抽象的编程，而不是针对具体方法的编程”。在我看来，设计模式的重点是如何搭建一个易于扩展、复用、修改和灵活利用的软件架构。七大设计原则，在我看来，都是为了这种软件架构所确立的。由于并非专业学软件/计算机的，目前对于设计原则的理解还比较片面，只是从文字上大概只其所以然，希望后续设计模式学习中，可以更深刻地理解它们。

简介

1994年，《设计模式：可复用面向对象软件的基础》一书正式将设计模式的概念引入到软件开发领域。设计模式是软件开发中一些常见问题的典型解决方案。

设计模式的几点认知
- 设计模式更类似于抽象的蓝图，而非具体的实现方法
- 设计模式可应用范围广，小模块和整套软件系统均可以应用
- 实际应用中，往往同时应用多个设计模式，部分模式可能只使用了其中一部分
- 设计模式的适用性和功能、设计、背景等有关，彼此没有好坏
面向设计对象的基本原则
- 针对接口编程，而不是针对实现编程
- 优先使用对象组合，而不是类继承
- 封装变化，将不变与变化的内容分开

设计原则

单一职责原则（The Single Responsibility Principle, SRP）

一个类应仅有一个更改它的原因，即只有一个职责
- 使用动机：违反此原则，当一个职责发生变化时，可能会影响其他职责，从而影响代码维护。
- 使用方式：相同的职责放到一类，不同的职责放到不同类。具体来说，如果存在大于一个动机去改变一个类，说明该类具有多于一个职责，应将职责分解。
- 使用原则：1. 每一个类实现的职责有清新明确的定义；2. 一个类的修改只对自身有影响，对其他类没有影响。
开闭原则（The Open-Closed Principle, OCP）

一个软件实体（类、模块、函数…）应对扩展开放，对修改关闭。通俗来讲，对于要增加的新功能或要调整的改动，尽量扩展代码而不是修改已有代码。
- 使用动机：面对需求改变可以保持系统相对稳定，使得系统在第一版以后不断推出新版本。
- 使用方式：对系统进行抽象化设计，创建抽象的类或者接口。一般来说，要通过对以下时机可能的变化，创建抽象，隔离以后发生的同类变化，包括：
  - 在开发工作展开前预测可能的变化
  - 展开后不久知道的可能发生的变化
  - 实际需求发生时带来的变化
- 使用原则：1. 仅对程序中呈现出频繁变化的部分做出抽象；2. 不要刻意对每个部分进行抽象，拒绝不成熟的抽象，它和抽象本身一样重要。
依赖倒置原则（Dependence Inversion Principle, DIP）

程序要依赖于抽象接口而非具体实现。即针对接口编程，不要针对实现编程。
- 使用动机：面对不同的具体实现做到易插拔，松耦合。
- 使用方式：1. 使用接口或者抽象类制定好规范，不涉及任何具体操作，把细节展现交给实现类去完成；2. 让程序中所有依赖关系都终止于抽象类或接口。
- 使用原则：1. 高层模块不依赖低层模块，两个都应该依赖抽象；2. 抽象不应该依赖于具体，具体应该依赖于抽象。
里氏替换原则（Liskov Substitution Principle， LSP）

所有引用父类的地方必须能透明地使用其子类的对象，而且程序行为没有变化。简单来说，子类型必须能够替换掉它们的父类型。

里氏替换原则是对开闭原则的补充。实现开闭原则的关键步骤是抽象化，而父类与子类的继承关系就是抽象化的具体实现，所以里氏替换原则是对实现抽象化的具体步骤的规范。
- 使用动机：父类可以复用，子类能够在父类基础上增加新的行为。
  
  只有当子类可以替换父类且软件单位功能不受影响的时候，父类才能真正被复用。
- 使用方式：1. 父类一般使用抽象类或接口；2. 抽象类定义公共对象和状态，接口定义公共行为；3. 子类通过继承父类和接口进行扩展。
- 使用原则：1. 子类方法的参数类型必须与父类相匹配或更抽象；2. 子类的返回值类型必须与父类或其子类相匹配；3. 子类方法的异常必须与父类抛出的异常（或其子类）相匹配；4. 子类不应该加强参数条件限制；5. 子类不能修改父类的私有成员变量。
迪米特原则（Law of Demeter, LoD)

又叫最小知识原则（Least Knowledge Principle, LKP）。一个类应尽可能少地与其他类发生相互作用，如果其中一个类需要调用另一个类的某一方法，可以通过第三者转发这个调用。
- 使用动机：强度类之间的松耦合。类之间的弱耦合有利于复用和扩展，同时一个弱耦合的类的修改不会对其他有关系的类造成波及。
- 使用方式：1. 在类的结构设计中，降低每一类的成员访问权限，不需要公开的方法和属性都不公开；2. 类之间不直接建立联系，通过中间类来中转；3. 如果一个方法放在本类中，既不产生新的类间依赖，也不造成负面影响，那么次方法就放在本类中。
  
  引入第三类中转调用，可能会产生大量的中间类或跳转类，导致系统和复杂性提高，可维护性降低。
- 使用原则：1. 减少公开方法和变量；2. 每个类对其他类知道的越少越好；3. 类不应该知道它所操作的对象的内部细节。
接口隔离原则（Interface Segregation Principle，ISP）

客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上。即接口尽量细化，同时接口中的方法尽量少。

*单一职责原则与接口隔离原则的区分：单一职责原则注重逻辑业务逻辑上类和接口的职责单一，接口隔离原则是要求接口太大时将它分割成更细小的接口，*使用接口的客户端仅需知道与之相关的方法即可。
合成/聚合复用原则（Composite/Aggragate Reuse Principle，CARP）

尽量使用合成/聚合，而不是通过继承达到复用的目的。在一个新的对象里面使用一些已用的对象，使之成为新对象的一部分；新的对象通过向向这些对象的委派达到复用已有功能的目的，而非通过继承来获得已有的功能。