再述 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://www.sgfoot.com

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