设计原则

6 大设计原则

  • 单一职责原则
  • 里氏替换原则
  • 依赖倒置原则
  • 接口隔离原则
  • 迪米特法则
  • 开闭原则

单一职责(Single Responsibility Principle)

  • 应该有且仅有一个原因引起类的变化

    对于职责的划分因项目而异,因环境而异。接口一定要做到单一职责,类的设计做到只有一个原因能引起变化。

里氏替换原则(Liskov Substitution Principle)

  • 所有引用基类的地方都必须能够透明的使用其子类的对象

    继承能够提高代码重用性,提高代码可扩展性。但具有侵入性,降低代码灵活性,增强了代码的耦合性。

    子类中方法的前置条件必须与超类中被覆写的方法的前置条件相同或者更宽松。

    在类中调用其他类时务必要使用父类或接口,如果不能使用,则说明类的设计已经违背了 LSP 原则。

    如果子类不能完整地实现父类的方法,或者父类的某些方法在子类中已经发生“畸变”,则建议断开父子继承关系,采用依赖、聚集、组合等关系代替继承。

依赖倒置原则(Dependency inversion principle)

  • 高层模块不应该依赖低层模块,两者都应依赖其抽象、抽象不应该依赖细节、细节应该依赖抽象。(面向接口编程)

    能够减少类间的耦合性。

    接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现, 实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化

接口隔离原则(Interface Segregation Principle)

  • 接口尽量细化、同时接口方法尽量少

    一个接口只服务于一个子模块或业务逻辑;通过业务逻辑压缩接口中的方法;已经污染的接口尽量去修改,若变更的风险较大,则采用适配器模式转化处理

迪米特法则(Law of Demeter)

  • 一个类应该对自己需要调用/耦合的类知道得最少。

    在实际应用中,如果一个类跳转两次以上才能访问到另一个类,就需要想办法进行重构了,跳转次数越多,系统越复杂,维护就越困难。

开闭原则(Open Close Principle)

  • 软件实体应该对扩展开放,对修改关闭

    软件实体应该通过扩展来实现变化,而不应该通过修改已有的代码来实现变化