设计原则 & 设计模式

前言

从6月入职网易前端实习到现在，在开发过程中越来越感慨设计原则和设计模式的重要性。软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的，我们要为不可预料的变化做好准备，因此就很有必要在编码的环节做足功夫，保障代码的易维护性、易拓展性、可读性、兼容性等。这可能也就是我们与前辈编写代码时的主要区别。在之前学校课程里也有教过这方面的知识但是自己觉得并没有很深入地去理解它们。于是便想写下这篇文章重新梳理一下设计原则和设计模式知识。

六大设计原则

在讲设计模式前首先对六大设计原则进行介绍

六大设计原则主要是指：

单一职责原则（Single Responsibility Principle）
开闭原则（Open Closed Principle）
里氏替换原则（Liskov Substitution Principle）
迪米特法则（Law of Demeter），“最少知道法则”
接口隔离原则（Interface Segregation Principle）
依赖倒置原则（Dependence Inversion Principle）

它们的英文首字母组合形成SOLID——稳定的（其中L字母重复取一个），代表这把这 6 个原则结合使用的好处是建立稳定、灵活、健壮的设计。

单一指责原则

一个类或接口只承担一个指责，有且仅有一个原因引起类的变更

优点：

类的复杂性降低，实现什么职责都有清晰明确的定义
复杂性降低，可读性提高
可读性提高，可维护性提高
变更引起的风险降低。如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有很大帮助

开闭原则

对拓展开放，对修改关闭（应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化）

是最基本的一个原则，提高了复用性以及可维护性

里氏替换原则

子类可以替换父类（只要父类能出现的地方，子类就可以出现，而且替换为子类也不会产生任何错误或异常）

在继承类时，务必重写（override）父类中所有的方法，尤其需要注意父类的protected方法（往往需要重写），子类尽量不要暴露自己的public方法供外界调用

四个层次规范：

子类必须完全实现父类的方法
子类中可以增加自己的特有方法
子类可以重载父类方法，但不能覆盖，且入参可以放大
子类实现抽象方法时，返回值可以是父类返回值的子类

迪米特原则

对象与对象直接应该尽可能少关联，减小类之间的耦合

核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类才能够易被复用

接口隔离原则

类间的依赖关系应该建立在最小的接口上，不要对外暴露没有实际意义的接口（一个接口不能过于臃肿，使用多个专一功能的接口比一个总接口好）

依赖倒置原则

面向接口编程，依赖于抽象而不依赖于具体类

高层模块不应该依赖于低层模块，而应该依赖于抽象。抽象不应依赖于细节，细节应依赖于抽象。

模块间的依赖通过抽象发生，实现类之间不直接发生依赖关系，其依赖关系通过接口或抽象类产生的
接口或抽象类不依赖于实现类
实现类依赖接口或抽象类

减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性

23 种设计模式

设计模式分类

设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案

设计模式分为三大类：

创建型模式：

用来描述 “如何创建对象”，它的主要特点是 “将对象的创建和使用分离”

共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式

结构型模式：

用来描述如何将类或对象按照某种布局组成更大的结构

共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式

行为型模式：

用来识别对象之间的常用交流模式以及如何分配职责

共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式

设计原则 & 设计模式

JS