细说 S.O.L.I.D

S.O.L.I.D 五原则（以下简称五原则）：

单一功能原则
开放封闭原则
里氏替换原则
接口隔离原则
依赖反转原则。

S.O.L.I.D 做为面向对象编程和面向对象设计的五个基本原则，在面向对象的软件开发史上做为“最佳实践”指导着人们开发出代码清晰可读、容易维护和扩展的系统。

S.O.L.I.D 由 Robert C. Martin (Uncle Bob) 总结提出。

Code rot

什么样的代码是烂代码呢？如何识别将来可能会演变成烂代码的代码呢？

刚性：小改变导致整个系统重写
脆弱性：一个模块的改变导致其他不相关模块行为变得不当，想象一下一台汽车因为电台的变动影响到了车窗的使用
不可迁移性：一个模块的内部组件不能提取到新环境使用，原因是组件间的耦合与强依赖。规避策略是将中央抽象与 low-level 细节分离
粘性：当构建和测试难以进行，需要花费大量的时间执行（例如：在充值处做了小改动，也需要花费时间去测试游戏各个环节能否正常运行）

人们主要能体会到软件中的两类价值：

帮助人们更好地做某件事，提高生产力，降低时间与金钱支出
软件的行为表现：满足现阶段的用户需求，同时能频繁地变动以满足用户的需求变更，且没有 Bug 与崩溃。

第一类价值的保证靠的的团队的产品等角色的发挥，而第二类价值的保证则需要工程师的软件架构设计来保证了，而 S.O.L.I.D 是应用最为广泛也最为基础的设计指导原则。

单一功能原则 - RSP

解释

一个类或类似的结构只做一件事，只因为一个原因而发生变动

详细阐述

类的一切数据与方法都应该与这个单一的职责有关，即凝聚力。但这并不意味着你的类只能包含一个方法或属性。

优点

降低类的复杂度
提高可维护性
提高可读性
降低需求变化带来的风险

示例

// Not good, **3** responsibility
class Employee {
    public Pay calculatePay() {...} # 1) calculation logic
    public void save() {...} # 2) database logic
    public String describeEmployee() {...} # 3) reporting logic
}

Modem 类的设计改进：
=>

开放封闭原则 - OCP

解释

软件中的对象（类，模块，函数等等）对扩展开放，对修改封闭。

详细阐述

现有代码应该只在下面三种情况进行修改：

现有代码里有 Bug 或错误
现有代码实现的需求发生了变动（例如之前确定的算法或逻辑发生了改变）

下面情况不应该需要改变现有代码，而能通过继承、多态来进行扩展即可变更软件的行为：

以前做过可预测的同类需求。例如在员工管理系统中需要新增一个员工类型，支付系统需要新增一种支付方式

通常的实现方法：对抽象编程，而不对具体编程；使用抽象类或接口，而不是使用具体的类；新功能的的增加通过实现继承抽象类或实现接口，而非改变已有代码来完成。

只有在将会发生的变化是可预测的情况下，OCP 才会有所帮助，所以你应当只有在类似的变化已经发生过的情况下使用它。

优点

扩展新功能时不容易引入新 Bug
新的功能添加无需对全部代码进行代码审查、单元测试
代码稳定性
解耦，增加弹性

实例

// Not Good
/**
 * 不难预料，将来可能支持除现金之外的收款方式
 * 这里直接写死成 acceptCash
 */
void checkOut(Receipt receipt) {
  Money total = Money.zero;
  for (item : items) {
    total += item.getPrice();
    receipt.addItem(item);
  }
  Payment p = acceptCash(total);
  receipt.addPayment(p);
}

// 将来需要新增一种收款方式，可能会被改成这样
void checkOut(Receipt receipt) {
  Money total = Money.zero;
  for (item : items) {
    total += item.getPrice();
    receipt.addItem(item);
  }
  Payment p;
  if (credit)
    p = acceptCredit(total);
  else
    p = acceptCash(total);
  receipt.addPayment(p);
}

// Good
public interface PaymentMethod {void acceptPayment(Money total);}

void checkOut(Receipt receipt, PaymentMethod pm) {
  Money total = Money.zero;
  for (item : items) {
    total += item.getPrice();
    receipt.addItem(item);
  }
  Payment p = pm.acceptPayment(total);
  receipt.addPayment(p);
}

里氏替换原则 - LSP

解释

任何基类可以出现的地方，子类一定可以出现。所有子类需要按照其基本类别的方式进行操作。子类可以扩展父类的功能，但不能改变父类原有的行为预期。

详细阐述

Liskov 提出的关于继承的原则：继承必须确保超类中所拥有的属性与方法在子类中仍然拥有。

Robert C. Martin 提出了更抽象的简化：子类必须能够替换成他们的基类。这也是里氏替换原则的精髓。

LSP 是继承复用的基石，只有当子类可以替换基类，软件单位的功能不受影响时，基类才能真正的被复用，而子类也可以在基类的基础上增加新的行为。

一般来说，如果超类的子类型做了超类的客户端所不期望的事情，那么这违背了 LSP。设想一个派生类抛出一个异常，超类不抛出，或者如果一个派生类有一些意想不到的副作用。

更具有指导意义的详细规范：

子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

优点

里氏替换原则是实现开放封闭原则的具体规范
见开放封闭原则的优缺点

示例

见链接

接口隔离原则 - ISP

解释

一个类不应该被强制依赖它不需要的接口成员。多个小的、特定的、具有内聚性的客户端接口要好于单个宽泛用途的、内聚性差的接口。

详细阐述

与单一职责原则的不同点：

单一职责原则注重的是对象的职责；而接口隔离原则注重对接口依赖的隔离
单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口，主要针对抽象，针对程序整体框架的构建

接口的粒度需要我们自己去把控，接口的粒度过小会造成接口数量过多，设计复杂化；接口粒度过大，就很容易违背接口隔离原则。

另见下方示例

优点

灵活性
避免接口臃肿

示例

// Not Good
public interface Messenger {
  askForCard();
  tellInvalidCard();
  askForPin();
  tellInvalidPin();
  tellCardWasSiezed();
  askForAccount();
  tellNotEnoughMoneyInAccount();
  tellAmountDeposited();
  tellBalance();
}

// Good
public interface LoginMessenger {
  askForCard();
  tellInvalidCard();
  askForPin();
  tellInvalidPin();	
}

public interface WithdrawalMessenger {
  tellNotEnoughMoneyInAccount();
  askForFeeConfirmation();
}

publc class EnglishMessenger implements LoginMessenger, WithdrawalMessenger {
  ...	
}

依赖反转原则 - DIP

解释

高层模块不应该依赖低层模块，所有模块都应该依赖抽象
抽象不应该依赖细节/具体
细节/具体应该依赖抽象

详细阐述

什么是依赖？

不是我自身的，却是我需要的，都是我所依赖的。
我若依赖你，我就不能离开你。

什么是高层模块？什么是低层模块？

类 A 直接依赖于类 B，假如要将类 A 修改为依赖类 C，则必须通过修改类 A 的代码来达成。这种场景下，类 A 一般是高层模块，负责复杂的业务逻辑。类 B 和 C 是底层模块，负责基本的原子操作。

什么是抽象？什么是细节？

抽象：抽象类或接口
细节：具体的实现类或实现方法

这里的依赖是什么？反转后的依赖变成了什么？

这里的依赖原本指高层模块对低层模块的依赖，倒置的依赖演变成实现类对接口或抽象类的依赖

反转怎么理解？

由于低层组件是对高层组件接口的具体实现，因此低层组件包的编译是依赖于高层组件的，这颠倒了传统的依赖关系。

优点

松散耦合
多人开发，提取模块的抽象，可以进行多人并行开发
违背了依赖反转原则，那么开放封闭原则也就无法实行

示例

// 模块 A
public interface Reader { char getchar(); }
public interface Writer { void putchar(char c)}

class CharCopier {
  void copy(Reader reader, Writer writer) {
    int c;
    while ((c = reader.getchar()) != EOF) {
      writer.putchar();
    }
  }
}

// 模块 B
public Keyboard implements Reader {...}
public Printer implements Writer {…}

// 应用
...
new CharCopier(new Keyboard(), new Writer());