Java面向对象设计原则总结.docx
- 文档编号:20195938
- 上传时间:2023-04-25
- 格式:DOCX
- 页数:28
- 大小:167.06KB
Java面向对象设计原则总结.docx
《Java面向对象设计原则总结.docx》由会员分享,可在线阅读,更多相关《Java面向对象设计原则总结.docx(28页珍藏版)》请在冰豆网上搜索。
Java面向对象设计原则总结
Java面向对象16种设计原则
一类的设计原则
1 依赖倒置原则-DependencyInversionPrinciple(DIP)
2 里氏替换原则-LiskovSubstitutionPrinciple(LSP)
3 接口分隔原则-InterfaceSegregationPrinciple(ISP)
4 单一职责原则-SingleResponsibilityPrinciple(SRP)
5 开闭原则-TheOpen-ClosedPrinciple(OCP)
二包的设计原则
6 重用发布等价原则-ReleaseReuseEquivalencyPrinciple(REP)
7 无环依赖原则-TheAcyclicDependenciesPrinciple(ADP)
8 稳定依赖原则-TheStableDependenciesPrinciple(SDP)
9 稳定抽象等价原则-TheStableAbstractionsPrinciple(SAP)
10 共同封闭原则-TheCommonClosurePrinciple(CCP)
11 全部重用原则-TheCommonReusePrinciple(CRP)
三扩展原则
12迪米特法则-LeastKnowledgePrinciple(LKP)
13黑盒原则-BBP(BlackBoxPrinciple)
14缺省抽象原则-DAP(DefaultAbstractionPrinciple)
15接口设计原则-IDP(InterfaceDesignPrinciple)
16不要构造具体的超类原则-DCSP(Don'tConcreteSupperclassPrinciple)
1.DependencyInversionPrinciple(DIP)-依赖倒置原则
依赖:
在程序设计中,如果一个模块a使用或调用了另一个模块b,我们称模块a依赖模块b。
高层模块与低层模块:
往往在一个应用程序中,我们有一些低层次的类,这些类实现了一些基本的或初级的操作,我们称之为低层模块;另外有一些高层次的类,这些类封装了某些复杂的逻辑,并且依赖于低层次的类,这些类我们称之为高层模块。
依赖倒置原则的2个重要方针:
A.高层模块不应该依赖于低层模块,二者都应该依赖于抽象
B.抽象不应该依赖于细节,细节应该依赖于抽象
为什么叫做依赖倒置(DependencyInversion)呢?
面向对象程序设计相对于面向过程(结构化)程序设计而言,依赖关系被倒置了。
因为传统的结构化程序设计中,高层模块总是依赖于低层模块。
问题的提出:
RobertC.Martin在原文中给出了“BadDesign”的定义:
1.系统很难改变,因为每个改变都会影响其他很多部分。
2.当你对某地方做一修改,系统的看似无关的其他部分都不工作了。
3.系统很难被另外一个应用重用,因为你很难将要重用的部分从系统中分离开来。
导致“BadDesign”的很大原因是“高层模块”过分依赖“低层模块”。
一个良好的设计应该是系统的每一部分都是可替换的。
如果“高层模块”过分依赖“低层模块”,一方面一旦“低层模块”需要替换或者修改,“高层模块”将受到影响;另一方面,高层模块很难可以重用。
比如,一个Copy模块,需要把来自Keyboard的输入复制到Print,即使对Keyboard和Print的封装已经做得非常好,但如果Copy模块里直接使用Keyboard与Print,Copy任很难被其他应用环境(比如需要输出到磁盘时)重用。
问题的解决:
为了解决上述问题,RobertC.Martin提出了OO设计的DependencyInversionPrinciple(DIP)原则。
DIP给出了一个解决方案:
在高层模块与低层模块之间,引入一个抽象接口层。
HighLevelClasses(高层模块)-->AbstractionLayer(抽象接口层)-->LowLevelClasses(低层模块)
抽象接口是对低层模块的抽象,低层模块继承或实现该抽象接口。
这样,高层模块不直接依赖低层模块,高层模块与低层模块都依赖抽象接口层。
当然,抽象也不依赖低层模块的实现细节,低层模块依赖(继承或实现)抽象定义。
RobertC.Martin给出的DIP方案的类的结构图:
PolicyLayer-->MechanismInterface(abstract)--MechanismLayer-->UtilityInterface(abstract)--UtilityLayer
类与类之间都通过AbstractLayer来组合关系。
2.LiskovSubstitutionPrinciple(LSP)-里氏替换原则
所有引用基类的地方必须能透明地使用其子类的对象。
也就是说,只有满足以下2个条件的OO设计才可被认为是满足了LSP原则:
A不应该在代码中出现if/else之类对子类类型进行判断的条件。
以下代码就违反LSP定义。
if(objtypeofClass1){
dosomething
}elseif(objtypeofClass2){
dosomethingelse
}
B子类应当可以替换父类并出现在父类能够出现的任何地方,或者说如果我们把代码中使用基类的地方用它的子类所代替,代码还能正常工作。
里氏替换原则LSP是使代码符合开闭原则的一个重要保证。
同时LSP体现了:
1)类的继承原则:
如果一个继承类的对象可能会在基类出现地方出现运行错误,则该子类不应该从该基类继承,或者说,应该重新设计它们之间的关系。
2)动作正确性保证:
从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。
类的继承原则:
RobertC.Martin举了Rectangle和Square的例子。
这里沿用这个例子,但用Java语言对其加以重写,并忽略了某些细节只列出下面的精要部分来说明里氏替换原则对类的继承上的约束。
1.classRectangle{
2. doublewidth;
3. doubleheight;
4.
5. publicdoublegetHeight(){
6. returnheight;
7. }
8. publicvoidsetHeight(doubleheight){
9. this.height=height;
10. }
11. publicdoublegetWidth(){
12. returnwidth;
13. }
14. publicvoidsetWidth(doublewidth){
15. this.width=width;
16. }
17.}
18.
19.classSquareextendsRectangle{
20. publicvoidsetHeight(doubleheight){
21. super.setHeight(height);
22. super.setWidth(height);
23. }
24.
25. publicvoidsetWidth(doublewidth){
26. super.setHeight(width);
27. super.setWidth(width);
28. }
29.}
classRectangle{
doublewidth;
doubleheight;
publicdoublegetHeight(){
returnheight;
}
publicvoidsetHeight(doubleheight){
this.height=height;
}
publicdoublegetWidth(){
returnwidth;
}
publicvoidsetWidth(doublewidth){
this.width=width;
}
}
classSquareextendsRectangle{
publicvoidsetHeight(doubleheight){
super.setHeight(height);
super.setWidth(height);
}
publicvoidsetWidth(doublewidth){
super.setHeight(width);
super.setWidth(width);
}
}
这里Rectangle是基类,Square从Rectangle继承。
这种继承关系有什么问题吗?
假如已有的系统中存在以下既有的业务逻辑代码:
voidg(Rectangler){
r.setWidth(5);
r.setHeight(4);
if(r.getWidth()*r.getHeight()!
=20){
thrownewRuntimeException();
}
}
则对应于扩展类Square,在调用既有业务逻辑时:
Rectanglesquare=newSquare();
g(square);
时会抛出一个RuntimeException异常。
这显然违反了LSP原则。
动作正确性保证:
因为LSP对子类的约束,所以为已存在的类做扩展构造一个新的子类时,根据LSP的定义,不会给已有的系统引入新的错误。
DesignbyContract
根据BertrandMeyer提出的DesignbyContract(DBC:
基于合同的设计)概念的描述,对于类的一个方法,都有一个前提条件以及一个后续条件,前提条件说明方法接受什么样的参数数据等,只有前提条件得到满足时,这个方法才能被调用;同时后续条件用来说明这个方法完成时的状态,如果一个方法的执行会导致这个方法的后续条件不成立,那么此方法也不应该正常返回。
现在把前提条件以及后续条件应用到继承子类中,子类方法应该满足:
1)前提条件不强于基类.
2)后续条件不弱于基类.
换句话说,通过基类的接口调用一个对象时,用户只知道基类前提条件以及后续条件。
因此继承类不得要求用户提供比基类方法要求的更强的前提条件,亦即,继承类方法必须接受任何基类方法能接受的任何条件(参数)。
同样,继承类必须顺从基类的所有后续条件,亦即,继承类方法的行为和输出不得违反由基类建立起来的任何约束,不能让用户对继承类方法的输出感到困惑。
这样,我们就有了基于合同的LSP,基于合同的LSP是LSP的一种强化。
在很多情况下,在设计初期我们类之间的关系不是很明确,LSP则给了我们一个判断和设计类之间关系的基准:
需不需要继承,以及怎样设计继承关系。
3.InterfaceSegregationPrinciple(ISP)-接口分隔原则
不能强迫用户去依赖那些他们不使用的接口。
换句话说,使用多个专门的接口比使用单一的总接口总要好。
它包含了2层意思:
1)接口的设计原则:
接口的设计应该遵循最小接口原则,不要把用户不使用的方法塞进同一个接口里。
如果一个接口的方法没有被使用到,则说明该接口过胖,应该将其分割成几个功能专一的接口。
2)接口的依赖(继承)原则:
如果一个接口a依赖(继承)另一个接口b,则接口a相当于继承了接口b的方法,那么继承了接口b后的接口a也应该遵循上述原则:
不应该包含用户不使用的方法。
反之,则说明接口a被b给污染了,应该重新设计它们的关系。
如果用户被迫依赖他们不使用的接口,当接口发生改变时,他们也不得不跟着改变。
换而言之,一个用户依赖了未使用但被其他用户使用的接口,当其他用户修改该接口时,依赖该接口的所有用户都将受到影响。
这显然违反了开闭原则,也不是我们所期望的。
下面我们举例说明怎么设计接口或类之间的关系,使其不违反ISP原则。
假如有一个Door,有lock,unlock功能,另外,可以在Door上安装一个Alarm而使其具有报警功能。
用户可以选择一般的Door,也可以选择具有报警功能的Door。
有以下几种设计方法:
ISP原则的违反例:
方法一:
在Door接口里定义所有的方法。
图:
但这样一来,依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。
违反了ISP原则。
方法二:
在Alarm接口定义alarm方法,在Door接口定义lock,unlock方法,Door接口继承Alarm接口。
跟方法一一样,依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。
违反了ISP原则。
遵循ISP原则的例:
方法三:
通过多重继承实现
Adapter设计模式的实现。
第2)种方案更具有实用性。
这种设计遵循了ISP设计原则。
方法四:
通过委托实现
在Alarm接口定义alarm方法,在Door接口定义lock,unlock方法。
接口之间无继承关系。
CommonDoor实现Door接口,
AlarmDoor有2种实现方案:
1)同时实现Door和Alarm接口。
2)继承CommonDoor,并实现Alarm接口。
该方案是继承方式的
小结
InterfaceSegregationPrinciple(ISP)从对接口的使用上为我们对接口抽象的颗粒度建立了判断基准:
在为系统设计接口的时候,使用多个专门的接口代替单一的胖接口。
4.SingleResponsibilityPrinciple(SRP)-单一职责原则
永远不要让一个类存在多个改变的理由。
换句话说,如果一个类需要改变,改变它的理由永远只有一个。
如果存在多个改变它的理由,就需要重新设计该类。
SRP(SingleResponsibilityPrinciple)原则的核心含意是:
只能让一个类有且仅有一个职责。
这也是单一职责原则的命名含义。
为什么一个类不能有多于一个以上的职责呢?
如果一个类具有一个以上的职责,那么就会有多个不同的原因引起该类变化,而这种变化将影响到该类不同职责的使用者(不同用户):
1,一方面,如果一个职责使用了外部类库,则使用另外一个职责的用户却也不得不包含这个未被使用的外部类库。
2,另一方面,某个用户由于某原因需要修改其中一个职责,另外一个职责的用户也将受到影响,他将不得不重新编译和配置。
这违反了设计的开闭原则,也不是我们所期望的。
职责的划分
既然一个类不能有多个职责,那么怎么划分职责呢?
Robert.CMartin给出了一个著名的定义:
所谓一个类的一个职责是指引起该类变化的一个原因。
如果你能想到一个类存在多个使其改变的原因,那么这个类就存在多个职责。
SingleResponsibilityPrinciple(SRP)的原文里举了一个Modem的例子来说明怎么样进行职责的划分,这里我们也沿用这个例子来说明一下:
SRP违反例:
Modem.java
interfaceModem{
publicvoiddial(Stringpno); //拨号
publicvoidhangup(); //挂断
publicvoidsend(charc); //发送数据
publiccharrecv(); //接收数据
}
咋一看,这是一个没有任何问题的接口设计。
但事实上,这个接口包含了2个职责:
第一个是连接管理(dial,hangup);另一个是数据通信(send,recv)。
很多情况下,这2个职责没有任何共通的部分,它们因为不同的理由而改变,被不同部分的程序调用。
所以它违反了SRP原则。
下面的类图将它的2个不同职责分成2个不同的接口,这样至少可以让客户端应用程序使用具有单一职责的接口:
让ModemImplementation实现这两个接口。
我们注意到,ModemImplementation又组合了2个职责,这不是我们希望的,但有时这又是必须的。
通常由于某些原因,迫使我们不得不绑定多个职责到一个类中,但我们至少可以通过接口的分割来分离应用程序关心的概念。
事实上,这个例子一个更好的设计应该是这样的,如图:
小结
SingleResponsibilityPrinciple(SRP)从职责(改变理由)的侧面上为我们对类(接口)的抽象的颗粒度建立了判断基准:
在为系统设计类(接口)的时候应该保证它们的单一职责性。
5.TheOpen-ClosedPrinciple(OCP)-开闭原则
开闭原则(OCP:
Open-ClosedPrinciple)是指在进行面向对象设计(OOD:
ObjectOrientedDesign)中,设计类或其他程序单位时,应该遵循:
-对扩展开放(open)
-对修改关闭(closed)
开闭原则是判断面向对象设计是否正确的最基本的原理之一。
根据开闭原则,在设计一个软件系统模块(类,方法)的时候,应该可以在不修改原有的模块(修改关闭)的基础上,能扩展其功能(扩展开放)。
A扩展开放:
某模块的功能是可扩展的,则该模块是扩展开放的。
软件系统的功能上的可扩展性要求模块是扩展开放的。
B修改关闭:
某模块被其他模块调用,如果该模块的源代码不允许修改,则该模块修改关闭的。
软件系统的功能上的稳定性,持续性要求是修改关闭的。
这也是系统设计需要遵循开闭原则的原因:
1)稳定性。
开闭原则要求扩展功能不修改原来的代码,这可以让软件系统在变化中保持稳定。
2)扩展性。
开闭原则要求对扩展开放,通过扩展提供新的或改变原有的功能,让软件系统具有灵活的可扩展性。
遵循开闭原则的系统设计,可以让软件系统可复用,并且易于维护。
开闭原则的实现方法
为了满足开闭原则的对修改关闭(closedformodification)原则以及扩展开放(openforextension)原则,应该对软件系统中的不变的部分加以抽象,在面向对象的设计中,
A可以把这些不变的部分加以抽象成不变的接口,这些不变的接口可以应对未来的扩展;
B接口的最小功能设计原则。
根据这个原则,原有的接口要么可以应对未来的扩展;不足的部分可以通过定义新的接口来实现;
C模块之间的调用通过抽象接口进行,这样即使实现层发生变化,也无需修改调用方的代码。
接口可以被复用,但接口的实现却不一定能被复用。
接口是稳定的,关闭的,但接口的实现是可变的,开放的。
可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能,实现软件系统的柔软扩展。
简单地说,软件系统是否有良好的接口(抽象)设计是判断软件系统是否满足开闭原则的一种重要的判断基准。
现在多把开闭原则等同于面向接口的软件设计。
开闭原则的相对性
软件系统的构建是一个需要不断重构的过程,在这个过程中,模块的功能抽象,模块与模块间的关系,都不会从一开始就非常清晰明了,所以构建100%满足开闭原则的软件系统是相当困难的,这就是开闭原则的相对性。
但在设计过程中,通过对模块功能的抽象(接口定义),模块之间的关系的抽象(通过接口调用),抽象与实现的分离(面向接口的程序设计)等,可以尽量接近满足开闭原则。
6.ReleaseReuseEquivalencyPrinciple(REP)-重用发布等价原则
包的内部关系方面(聚合性)的原则,重用粒度等价于发布粒度。
重用主要是从用户的观点来看的。
对用户来说,使用某个发布单位(组件,类,类群等),如果作者因为某种原因对其作了修改而发布了一个新的版本,用户会期望在升级为新版本之后,不会影响到原系统的正常运作。
也就是说,对于一个可重用(能供其它用户或系统使用)的元素(组件,类,类群等),作者应该承诺新版本能够兼容旧版本。
否则,用户将拒绝使用该元素。
RobertC.Martin给出的对重用的定义:
代码可以看作为可重用的代码,当且仅当:
-它的使用者(下称用户)无需看它的源代码
-用户只需联结静态库或包含动态库
-当库发生改变(错误纠正,功能增强)时,用户只需要得到一个新的版本便能集成到原有的系统
怎么做到重用呢?
一个组件要做到能够重用,它必须有一个得到良好设计的结构,它所包含所有元素必须也是可以重用的。
因为如果一个为重用而设计的发布单位里,包含了不可重用的元素,当不可重用的元素发生改变时,用户也不得不改变原有系统以适应新的版本。
这显然违反了重用的定义规则。
也就是说,一个为重用目的而设计的发布单位里,不能包含不可重用的元素;如果包含了不可重用的元素,它将变得不可重用。
发布单位
当用户使用的重用组件被作者修改后,用户希望得到通知,然后决定是否升级或升级的时机。
为了能使升级后的系统也能正常运作,用户也希望作者有一个规范的发布,包括版本号,类库的说明等等。
一旦用户决定升级新版本,不管这些修改是否影响到用户,用户也不得不包含新版本所包含的所有类库。
REP规定重用粒度不能小于发布粒度,所有重用元素也必须被一起发布。
发布粒度可以为包(组件)或类等实体,但一个应用往往包含了很多类,所以,具有更大的尺度的包(组件)更加适合作为发布粒度。
重用发布等价原则为我们指明了包的设计方针:
一个包中的元素(类)要么都可重用,要么都不可重用。
小结
重用发布等价原则(REP)从用户观点的角度上为我们规范了包设计的原则:
在设计包时,包中应该包含的元素要么都可以重用,要么都不可以重用。
7.TheAcyclicDependenciesPrinciple(ADP)-无环依赖原则
包之间的依赖结构必须是一个直接的无环图形(DAG)。
也就是说,在依赖结构中不允许出现环(循环依赖)。
换成另一个说法是:
包间依赖
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Java 面向 对象 设计 原则 总结