设计模式

Posted 2021-03-16 xiaolin-qian

常见的设计原则：

一：SOLID 原则　　　　

　　1.单一职责原则（SRP）--Single Responsibility Principle

　　　　一个类只负责完成一个职责或者功能。不要设计大而全的类，要设计粒度小、功能单一的类。单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性。

　　　　判断依据：出现以下情况则认为不符合单一原则

　　　　　　类中的代码行数、函数或者属性过多；

　　　　　　类依赖的其他类过多，或者依赖类的其他类过多；

　　　　　　私有方法过多；

　　　　　　比较难给类起一个合适的名字；

　　　　　　类中大量的方法都是集中操作类中的某几个属性。

　　2.开闭原则（OCP）--Open Closed Principle

　　　　添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。

　　　　如何做到开闭原则：

　　　　　　我们要时刻具备扩展意识、抽象意识、封装意识。在写代码的时候，我们要多花点时间思考一下，这段代码未来可能有哪些需求变更，如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，在不改动代码整体结构、做到最小代码改动的情况下，将新的代码灵活地插入到扩展点上。

　　3.里式替换原则（LSP）--Liskov Substitution Principle

　　　　父类定义了函数的“约定”（或者叫协议），那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。这里的约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。

　　　　

　　　　里式替换和多态的区别：

　　　　　　态是面向对象编程的一大特性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计原则，用来指导继承关系中子类该如何设计，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑及不破坏原有程序的正确性。

　　4.接口隔离原则（ISP）--Interface Segregation Principle

　　　　理解“接口隔离原则”的重点是理解其中的“接口”二字。这里有三种不同的理解。如果把“接口”理解为一组接口集合，可以是某个微服务的接口，也可以是某个类库的接口等。如果部分接口只被部分调用者使用，我们就需要将这部分接口隔离出来，单独给这部分调用者使用，而不强迫其他调用者也依赖这部分不会被用到的接口。如果把“接口”理解为单个 API 接口或函数，部分调用者只需要函数中的部分功能，那我们就需要把函数拆分成粒度更细的多个函数，让调用者只依赖它需要的那个细粒度函数。如果把“接口”理解为 OOP 中的接口，也可以理解为面向对象编程语言中的接口语法。那接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数。

　　　　接口隔离原则与单一职责原则的区别：

　　　　单一职责原则针对的是模块、类、接口的设计。接口隔离原则相对于单一职责原则，一方面更侧重于接口的设计，另一方面它的思考角度也是不同的。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

　　5.依赖反转原则（DIP）--Dependency Inversion Principle

　　　　相关概念梳理：

　　　　1. 控制反转

　　　　　　实际上，控制反转是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。这里所说的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。

　　　　2. 依赖注入

　　　　　　依赖注入和控制反转恰恰相反，它是一种具体的编码技巧。我们不通过 new 的方式在类内部创建依赖类的对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类来使用。

　　　　3. 依赖注入

　　　　　　框架我们通过依赖注入框架提供的扩展点，简单配置一下所有需要的类及其类与类之间依赖关系，就可以实现由框架来自动创建对象、管理对象的生命周期、依赖注入等原本需要程序员来做的事情。

　　　　4. 依赖反转原则

　　　　　　依赖反转原则也叫作依赖倒置原则。这条原则跟控制反转有点类似，主要用来指导框架层面的设计。高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。

二：KISS 原则 --Keep It Simple and Stupid

　　　　 尽量保持简单。

　　　　　　代码指导原则：

　　　　　　　　不要使用同事可能不懂的技术来实现代码；

　　　　　　　　不要重复造轮子，要善于使用已经有的工具类库；

　　　　　　　　不要过度优化。

三：YAGNI 原则 --You Ain’t Gonna Need It

　　不要去设计当前用不到的功能；不要去编写当前用不到的代码。实际上，这条原则的核心思想就是：不要做过度设计

四：DRY 原则 --Don’t Repeat Yourself

　　不要写重复的代码。

五：迪米特法则（LOD）--Law of Demeter

　　不该有直接依赖关系的类之间，不要有依赖

　　有依赖关系的类之间，尽量只依赖必要的接口

　　迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。

 

未完待续。。。。

 

 

 

 

 

 

注：文章内容来源 极客时间 王争《设计模式之美》