再述 SOLID 原则

再述 SOLID 原则，因为这些原则是设计模式的基石，所有的模式都是基于这些原则展开的。

单一职责原则

经典定义：应该有且仅有一个原因引起”类“的变更。(不仅仅适应于类，还适应于方法，接口，函数等)

好处：

  1. 类的复杂性降低，实现什么职责都有清晰的定义。
  2. 可读性提高，复杂性降低，那当然可读性提高了。
  3. 可维护性提高，可读性提高，那当然更容易维护了。
  4. 变更引 起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

一句话：单一职责原则，最重要做到单一职责，类的设计尽量做到只有一个原因引起变化。

里氏替换原则

经典定义：父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常。使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行，有子类出现的地方，父类未必能适应。

继承即有优点与有缺点，为了平衡引入里氏替换原则。

继承的优点：

  1. 代码共享，减少创建类的工作量。
  2. 提高代码的重用性。
  3. 子类可以形似父类，但又异于父类。
  4. 提高代码的可扩展性。
  5. 提高产品或项目的开放性。

继承的缺点：

  1. 继承是侵入性的。
  2. 降低代码的灵活性。
  3. 增强了耦合性。

一句话：父类出现的地方子类就可以出现且无异常。反之不行。

依赖倒置原则

经典定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象。抽象不应该依赖细节。细节应该依赖抽象。

每一个逻辑的实现都是由原子逻辑组成的，不可以分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。

抽象是指接口或抽象类，两者都是不能直接被实例化的。

细节就是实现类，实现接口或继承抽象而产生的类就是细节。

优点：

  1. 减少类间的耦合性。
  2. 易于扩展

依赖的三种写法：

  1. 构造函数传递依赖对象。
  2. Setter 方法传递依赖对象。
  3. 接口声明依赖对象即依赖注入。

一句话：面向接口编程。

接口隔离原则

经典定义：客户端不应该依赖它不需要的接口。或类间依赖关系应该建立在最小的接口上。

  1. 接口要尽量小。
  2. 接口要高内聚。
  3. 定制服务 。
  4. 接口设计是有限度的。
    1. 接口的设计粒度越小，系统越灵活

一句话：接口尽量细化，同时接口中的方法尽量少。

迪米特法则

经典定义：一个对象应该对其他对象有最少的了解。

  1. 只与直接的朋友通信。
  2. 朋友间也是有距离的。
    1. 尽量不要对外公布太多的 public 方法和非静态的 public 变量。
    2. 多使用 private 权限。
  3. 是自己的就是自己的。
    1. 如果一个方法放在本类中，即不增加类间的关系，也对本类不产生负面影响，那就放置在本类中。
  4. 谨慎使用 Serializable

一句话：一个对象应该对自己需要耦合或调用的类知道得最少。

开闭原则

开闭原则是最基础的一个原则。也是前五个原则的精神领袖。

经典定义：对修改关闭，对扩展开放。

  1. 开闭原则有于利测试。
  2. 开闭原则可以提高复用性。
  3. 可以原则可以提高维护性。

一句话：开闭原则是其它原则的精神领袖。

总结

  1. 如图所示，开闭原则是以上5种原则的精神领袖，贯穿始终。
  2. 单一原则与迪米特原则更像一位导师，为了更好的指导每一个类，方法和接口的设计。
  3. 单一原则强调地是单一职责，仅有一个原因引起。
  4. 迪米特原则强调不依赖过多的关系，仅依赖直接关系，避免交叉依赖导致系统复杂难以维护。
  5. 里氏替换原则更像一种约束，保证替换的准确性。
  6. 接口隔离原则是避免拥肿的方法堆积，只设计需要的接口，保持接口的单一性，复杂的接口则采用组合实现。
  7. 依赖倒置原则是整个接口设计的灵魂，永远底层或细节依赖抽象。保证系统接口的稳定性，规范性。

关于我

我的博客：https://yezihack.github.io

欢迎关注我的微信公众号【空树之空】，共同学习，一起进步~ 空树之空