设计模式之六大设计原则
软件设计模式,简称设计模式,它是一种反反复复被使用,多数人经过分类编目的,代码设计经验的总结。使用设计模式可以为了减少重复的代码,让代码变得更加简洁,让人更加容易理解,保证代码的可靠性,程序可重复性。
- 单一原则(Single Responsibility Principle)
- 里氏替换原则(LSP liskov substitution principle)
- 依赖倒置原则(dependence inversion principle)
- 接口隔离原则(interface segregation principle)
- 迪米特原则(law of demeter LOD)
- 开闭原则(open closed principle)
单一原则
- 原则思想:一个类只负责一件事情,且职责需清晰,各个职责的程序改动,不影响其它程序。
- 问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。
- 解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。
- 优点:降低类和类的耦合,提高可读性,增加可维护性和可拓展性,降低可变性的风险。
里氏替换原则
- 原则思想:使用的基类可以在任何地方使用继承的子类,完美的替换基类。
- 问题由来:有一功能P1,由类A完成。现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障。
- 解决方案:当使用继承时,遵循里氏替换原则。类B继承类A时,除添加新的方法完成新增功能P2外,尽量不要重写父类A的方法,也尽量不要重载父类A的方法。
- 优点:增加程序的健壮性,即使增加了子类,原有的子类还可以继续运行,互不影响。
依赖倒置原则
- 原则思想:高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象,抽象不应该依赖于具体实现,具体实现应该依赖于抽象。
- 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。
- 解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。
- 优点:可以减少需求变化带来的工作量,做并行开发更加友好。
接口隔离原则
- 原则思想:类和类之间应该建立在最小接口的上。
- 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法。
- 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
- 优点:提高程序的灵活度,提高内聚,减少对外交互,使得最小的接口做最多的事情。
迪米特原则(最少知道原则)
- 原则思想:一个对象应当对其他对象有尽可能少地了解,简称类间解耦
- 问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。
- 解决方案:尽量降低类与类之间的耦合,一个类尽量减少自己对其他对象的依赖,原则是低耦合,高内聚,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。
优点:低耦合,高内聚。
开闭原则
- 原则思想:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
- 问题由来:在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试。
- 解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。
- 优点:单一原则告诉我们,每个类都有自己负责的职责,里氏替换原则不能破坏继承关系的体系。
就先说到这
\color{#008B8B}{ 就先说到这}
就先说到这
在下
A
p
o
l
l
o
\color{#008B8B}{在下Apollo}
在下Apollo
一个爱分享
J
a
v
a
、生活的小人物,
\color{#008B8B}{一个爱分享Java、生活的小人物,}
一个爱分享Java、生活的小人物,
咱们来日方长,有缘江湖再见,告辞!
\color{#008B8B}{咱们来日方长,有缘江湖再见,告辞!}
咱们来日方长,有缘江湖再见,告辞!