设计原则

设计原则

单一职责原则（SRP）

SRP （Single Responsibility Principle）

原则描述

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

判断依据

1. 类中的代码行数、函数或属性过多；
2. 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想；
3. 私有方法过多；
4. 很难用业务名词概括类名时，说明类的职责定义不够清晰；
5. 类中大量的方法都是操作类中的某几个属性，就需要考虑将这个几个属性抽离成类；

开闭原则（OCP）

OCP（Open Close Principle）

原则描述

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

提高代码的扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（装饰、策略、模板、职责链、状态）。

里式替换原则（LSP）

LSP（Liskov Substitution Principle）

原则描述

子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变以及正确性不被破坏。

多态是面向对象的一大特性，也是面向对象编程语言的一种语法。

里式替换原则是一种设计原则，是用来指导继承关系中子类该如何设计的，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。

接口隔离原则（ISP）

ISP（Interface Segregation Principle）

原则描述

如果接口理解为一组接口集合，接口调用方不应该被强迫依赖它不需要的接口。在设计微服务或者类库接口时，如果部分接口只能被部分调用者使用，那么就需要将这部分接口隔离出来，单独给对应的调用者使用，而不是强迫其他调用者也依赖这部分不会被用到的接口。

如果接口理解为单个API接口或函数，部分调用者只需要函数中的部分功能，那就需要吧函数拆分成粒度更细的多个函数，让调用者只依赖它需要的那个细粒度函数。

如果把接口理解为OOP中的接口，那接口设计的时候，应尽量单一，不要让接口的实现类或者调用者，依赖不需要的接口函数；

单一职责与接口隔离

单一职责原则针对的是模块、类、接口的设计。

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

依赖倒置原则（DIP）

原则描述

DIP（Dependency Inversion Principle）

高层模块不依赖低层模块，高层模块与低层模块共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。

控制反转

控制反转 IOC（Inversion Of Control）

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

依赖注入

依赖注入 DI（Dependency Injection）

不通过New的方式在类内部创建依赖类对象，而是将依赖类对象唉外部创建好之后，通过构造函数。函数函数等方式传递给类使用；

通过依赖注入的方式将依赖的类对象传递进来，这样提高了代码的扩展性，就可以灵活的替换依赖的类。

public interface MessageSender {
  void send(String cellphone, String message);
}
// 短信发送类
public class SmsSender implements MessageSender {
  @Override
  public void send(String cellphone, String message) {
  }
}
// 站内信发送类
public class InboxSender implements MessageSender {
  @Override
  public void send(String cellphone, String message) {
  }
}
public class Notification {
  private MessageSender messageSender;
  
  public Notification(MessageSender messageSender) {
    this.messageSender = messageSender;
  } 
  public void sendMessage(String cellphone, String message) {
    this.messageSender.send(cellphone, message);
  }
}

//使用Notification
MessageSender messageSender = new SmsSender();
Notification notification = new Notification(messageSender);

依赖注入框架

依赖注入框架（DI Framework）

处理项目中类对象的创建和依赖注入工作的框架，称为依赖注入框架，该框架本身与具体的业务无关。

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

生产中用的框架：Java Spring、Google Guice、Pico Container、Butterfly Container；Spring框架的控制反转主要是通过依赖注入来实现的。

Tomcat 是运行 Java Web 应用程序的容器。我们编写的 Web 应用程序代码只需要部署在 Tomcat 容器下，便可以被 Tomcat 容器调用执行。按照之前的划分原则，Tomcat 就是高层模块，我们编写的 Web 应用程序代码就是低层模块。Tomcat 和应用程序代码之间并没有直接的依赖关系，两者都依赖同一个“抽象”，也就是 Servlet 规范。Servlet 规范不依赖具体的 Tomcat 容器和应用程序的实现细节，而 Tomcat 容器和应用程序依赖 Servlet 规范。

DRY原则

原则描述

DRY原则（Don’t Repeat Yourself）

不要写重复的代码。

三种情况：实现逻辑重复、功能语义重复、代码执行重复。

实现逻辑重复，但功能语义不重复的代码，并不违反 DRY 原则；实现逻辑不重复，但功能语义重复的代码，也算是违反 DRY 原则；除此之外，代码执行重复也算是违反 DRY 原则；

提高代码复用性方法

1. 减少代码耦合
2. 满足单一职责原则
3. 模块化
4. 业务与非业务逻辑分离
5. 通用代码下沉
6. 继承、多态、抽象、封装
7. 应用模板等设计模式

KISS原则

原则描述

KISS原则

Keep It Simple and Stupid.

Keep It Short and Simple.

Keep It Simple and Straightforward

代码的可读性和可维护性是衡量代码质量非常重要的两个标准，而 KISS 原则就是保持代码可读和可维护的重要手段。

代码足够简单，也就意味着很容易读懂，bug 比较难隐藏。即便出现 bug，修复起来也比较简单

判断依据

1. 不要使用同事可能不懂的技术来实现代码
2. 不要重复造轮子，要善于使用已经有的工具类库
3. 不要过度优化

YAGNI原则

原则描述

YAGNI原则（You Ain’t Gonna Need It）

不要去设计当前用不到的功能；不要去编写当前用不到的代码，不要做过度设计。

LOD法则

原则描述

迪米特法则 LOD（Law of Demeter）

不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。

高内聚&低耦合

所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中。所谓松耦合指的是，在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖类的代码改动。