Java设计原则 - 开闭原则

六大设计原则

Java设计原则 - 单一职责原则

Java设计原则 - 里氏替换原则

Java设计原则 - 依赖倒置原则

Java设计原则 - 接口隔离原则

Java设计原则 - 迪米特法则

Java设计原则 - 开闭原则

定义

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭

在所有设计原则的定义中，开闭原则的定义是最模糊的，只告诉设计软件时，应该对扩展开放，对修改关闭。OK，这样的原则，说等于没说？！

其实不然，我觉得开闭原则，是我们设计软件的最终遵循的原则。我们不放回头看看之前说的五个原则，你会发现每个原则都是尽量做到对扩展开放，对修改关闭的效果。

回顾

在此，我们回顾一下之前学过的五个原则：

单一职责原则

一个类应该只负责一项职责，尽量做使类变更的原因只有一个。如果类出现职责扩散，考虑职责划分，由多个类去负责。保持原有的职责不变（对修改关闭），增加类去负责扩散的职责（对扩展开放），这正符合开闭原则。

里氏替换原则

父类存在的地方，由子类代替之后，程序运行的行为不变。客户类中如果使用父类定义，当需要代替为子类时，客户类可以不用修改任何代码。增加子类（对扩展开放），用子类代替父类，客户类不用修改代码（对修改关闭），这也符合开闭原则。

依赖倒置原则

高层模块不应该直接依赖底层模块，应该通过依赖抽象和底层模块产生依赖关系。高层模块不应该依赖底层模块具体某各类，应该依赖底层模块某个抽象类或接口，这样当底层模块扩展时（对扩展开放），只要还符合抽象类或接口的规范，高层模块不用做任何修改（对修改关闭），也是符合开闭原则的。

接口隔离原则

客户类不应该依赖它不需要的接口。依赖几个专用的接口要比依赖一个综合的接口更灵活，通过分散定义多个接口，可以预防外来变更的扩散，这也是符合开闭原则的。

迪米特法则（最少知道原则）

只与朋友类通信，不与陌生类说话，但是也不能与朋友类太熟悉。减少对陌生类的依赖，不论陌生类怎么扩展（对扩展开放），对客户类不会有任何影响（对修改关闭）；也不要知道太多朋友类细节，细节由朋友类自己管理，无论怎么修改细节（对扩展开发），客户类值调用最终实现的方法，当然也不会受影响（对修改关闭）。