六大设计原则
- Java设计原则 - 单一职责原则
- Java设计原则 - 里氏替换原则
- Java设计原则 - 依赖倒置原则
- Java设计原则 - 接口隔离原则
- Java设计原则 - 迪米特法则
- Java设计原则 - 开闭原则
定义
一个软件实体如类、模块和函数应该对扩展开放,对修改关闭
在所有设计原则的定义中,开闭原则的定义是最模糊的,只告诉设计软件时,应该对扩展开放,对修改关闭。OK,这样的原则,说等于没说?!
其实不然,我觉得开闭原则,是我们设计软件的最终遵循的原则。我们不放回头看看之前说的五个原则,你会发现每个原则都是尽量做到对扩展开放,对修改关闭的效果。
回顾
在此,我们回顾一下之前学过的五个原则:
-
单一职责原则
一个类应该只负责一项职责,尽量做使类变更的原因只有一个。如果类出现职责扩散,考虑职责划分,由多个类去负责。保持原有的职责不变(对修改关闭),增加类去负责扩散的职责(对扩展开放),这正符合开闭原则。
-
里氏替换原则
父类存在的地方,由子类代替之后,程序运行的行为不变。客户类中如果使用父类定义,当需要代替为子类时,客户类可以不用修改任何代码。增加子类(对扩展开放),用子类代替父类,客户类不用修改代码(对修改关闭),这也符合开闭原则。
-
依赖倒置原则
高层模块不应该直接依赖底层模块,应该通过依赖抽象和底层模块产生依赖关系。高层模块不应该依赖底层模块具体某各类,应该依赖底层模块某个抽象类或接口,这样当底层模块扩展时(对扩展开放),只要还符合抽象类或接口的规范,高层模块不用做任何修改(对修改关闭),也是符合开闭原则的。
-
接口隔离原则
客户类不应该依赖它不需要的接口。依赖几个专用的接口要比依赖一个综合的接口更灵活,通过分散定义多个接口,可以预防外来变更的扩散,这也是符合开闭原则的。
-
迪米特法则(最少知道原则)
只与朋友类通信,不与陌生类说话,但是也不能与朋友类太熟悉。减少对陌生类的依赖,不论陌生类怎么扩展(对扩展开放),对客户类不会有任何影响(对修改关闭);也不要知道太多朋友类细节,细节由朋友类自己管理,无论怎么修改细节(对扩展开发),客户类值调用最终实现的方法,当然也不会受影响(对修改关闭)。