设计原则

设计原则

SOLID

单一职责原则(SRP)

概念

SRP（Single Responsibility Principle）

A class or module should have a single reponsibility（一个类或者模块只负责完成一个职责(或者功能））

如何判断职责是否单一

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

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

私有方法过多；

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

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

开闭原则(OCP)

Open Closed Principle

原则的设计初衷

保证原有的代码的正常运行，不破坏原有的单元测试

对拓展开放是为了应对变化(需求)，对修改关闭是为了保证已有代码的稳定性；最终结果是为了让系统更有弹性！

提高代码扩展性的方法

多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态等）

扩展意识、抽象意识、封装意识

代码的修改是在所难免的，尽量让修改操作更集中、更少、更上层，尽量让最核心、最复杂的那部分逻辑代码满足开闭原则。

缺点

遵循开闭原则，往往会降低代码的可读性

里式替换原则(LSP)

Liskov Substitution Principle

Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it。(子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。)

违反里式替换原则

子类违背父类声明要实现的功能

子类违背父类对输入、输出、异常的约定

子类违背父类注释中所罗列的任何特殊说明

判断违反里式替换小窍门

运行父类单元测试，是否能够通过

与多态的区别

LSP与多态关注角度不同，多态是面向对象编程的一大特性，而LSP是设计原则

接口隔离原则(ISP)

Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use。（客户端不应该强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者）

“接口”的理解

一组 API 接口集合

单个 API 接口或函数

OOP 中的接口概念

不过度设计大而全的接口，尽量设计小而单一的接口

优点

灵活、易扩展、易复用

依赖反转原则(DIP)

Dependency Inversion Principle

作用

主要用指导框架层面的设计。

控制反转（IOC）

Inversion Of Control

“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程可以通过框架来控制。流程的控制权从程序员“反转”到了框架。

依赖注入（DI）

Dependency Injection

不通过 new() 的方式在类内部创建依赖类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类使用。

将对象的创建移动到更加上层的代码。

优点： 易扩展。

依赖注入框架(DI Framework)

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

KISS

Keep It Short and Simple.（尽量保持简单）

使用建议

不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。

不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出 bug 的概率会更高，维护的成本也比较高。

不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。

YAGNI

You Ain’t Gonna Need It 你不会需要它（不要做过度设计）

不过度设计，但要考虑到扩展点

DRY

Don’t Repeat Yourself （不要写重复的代码）

重复场景

实现逻辑重复

实现逻辑重复，但工作语义不重复，本质上还是做了两件不重复的事情

不违反DRY原则

示例：判断isVaildUserName和isVaildPassword逻辑重复，但是功能不同

功能语义重复

两个函数的命名不同，实现逻辑不同，但功能是相同的(尽管两段代码的实现逻辑不重复，但语义重复，也就是功能重复)

违反DRY原则

代码执行重复

某些判断逻辑重复执行，违反DRY原则 或者说多了一些不必要的判断

迪米特法则/最小知识原则

The Least Knowledge Principle。（最小知识原则）

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.（每个模块（unit）只应该了解那些与它关系密切的模块（units: only units “closely” related to the current unit）的有限知识（knowledge）。或者说，每个模块只和自己的朋友“说话”（talk），不和陌生人“说话”（talk）

不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）。