面对对象的六大原则

面对对象的六大原则

1. 单一职责原则(Single Responsibility Principle)

  • 就一个类而言,应该仅有一个引起它变化的原因。
  • 两个完全不一样的功能就不应该放在一个类中。
  • 一个类中应该是一组相关性很高的函数、数据的封装。

2. 开闭原则(Open Close Principle)

  • 软件中的对象(类、模块、函数等)应该对于拓展是开放的,对于修改是封闭的。
  • 尽量通过扩展的方式来对实现原有代码的变化、升级和维护,而不是通过修改已有的代码来实现。
  • 程序一旦开发完成,程序中一个类的实现只因错误而被修改,新的或者改变的特性应该通过新建不同的类实现,新建的类可以通过继承的方式来重用原类的代码。
  • 代码本身写的结构不好,就应该尽早地重构,以便是代码恢复到正常的“进化”,而不是通过继承等方式来添加新的实现,这会导致类型的膨胀以及历史遗留代码的冗余。

3. 里氏替换原则(Liskov Subsititution Principle)

  • 任何基类可以出现的地方,子类一定可以出现。
  • 里氏替换原则核心是 抽象 ,依赖于 继承多态 两大特性。
  • 建立抽象,通过抽象建立规范。具体的实现在运行时替换掉抽象,保证系统的扩展性、灵活性。
  • 抽象是走向代码优化的第一步。

4. 依赖倒置原则(Dependence Inversion Principle)

  • 高层模块不应该依赖底层模块,两者都应该依赖其抽象。
  • 抽象不应该依赖细节。
  • 细节应该依赖抽象。
  • 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象产生的。

5. 接口隔离原则(InterfaceSegregation Principles)

  • 客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。

6. 迪米特原则(Law Of Demeter)

  • 一个类应该对自己需要耦合或调用的类知道得最少,类的内部如何实现与调用者或者依赖者没关系,调用者或者依赖者只需要知道它需要的方法即可,其他的一概不管。

总结

  • 抽象、单一职责、最小化。
  • 在应用开发过程中,最难的不是完成应用的开发工作,而是在后续的升级、维护过程中让应用系统能够拥抱变化。

你可能感兴趣的:(设计模式,设计模式)