提高面向对象设计复用性的设计原则课件_第1页
提高面向对象设计复用性的设计原则课件_第2页
提高面向对象设计复用性的设计原则课件_第3页
提高面向对象设计复用性的设计原则课件_第4页
提高面向对象设计复用性的设计原则课件_第5页
已阅读5页,还剩58页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

提高面向对象设计复用性的设计原则面向对象的设计原则6/6/20231设计目标可扩展性(Extensibility):新功能易加入系统。灵活性(Flexibility):允许代码修改平稳发生,不会涉及很多其他模块。可插入性(Pluggability):容易将一个类换为另一个具有同样接口的类。6/6/20232软件复用重要性较高的生产率较高的软件质量恰当使用复用,可改善系统的可维护性6/6/20233使一个系统可在更高的层次上提供了可复用性抽象化和继承:使概念和定义可复用多态:使实现和应用可复用抽象化和封装:可保持和促进系统的可维护性面向对象设计6/6/20234抽象层次是一个应用系统作战略性判断和决定的地方,那么抽象层次就应当是较为稳定的,应当是复用的重点。复用的焦点不再集中在函数和算法等具体实现细节上,而是集中在最重要的含有宏观商业逻辑的抽象层次上。既然如果抽象层次的模块相对独立于具体层次的模块的话,那么具体层次内部的变化就不会影响到抽象层次的结构,所以抽象层次的复用就会较为容易。复用6/6/20235面向对象设计中,可维护性复用是以设计原则和设计模式为基础的。面向对象复用6/6/202361.开闭原则OCP:Open-ClosedPrinciple2. 里氏替换原则LSP:LiskovSubstitutionPrinciple3. 依赖倒转原则DIP:DependencyInversionPrinciple4. 接口隔离原则ISP:InterfaceSegregationPrinciple5. 组合复用原则CRP:Compositoin

ResusePrinciple6. 迪米特法则LoD:LawofDemeter7.单一职责原则(SRP)面向对象设计原则6/6/20237软件组成实体应该是对扩展可扩展的,但是对修改是关闭的。(SoftwareEntitiesShouldBeOpenForExtension,ButClosedForModification)1.开-闭原则OCP6/6/20238开放-封闭法则认为应该试图去设计出永远也不需要改变的模块。关键在于抽象化:可给系统定义一个一劳永逸,不再更改的抽象设计,此设计允许有无穷无尽的行为在实现层被实现。抽象层预见所有扩展。PC外设开-闭原则6/6/20239一个软件系统的所有模块不可能都满足OCP,但是应该努力最小化这些不满足OCP的模块数量。

开-闭原则6/6/202310PublicclassPart{privatedoublebasePrice;publicvoidsetPrice(doubleprice){

basePrice=price;}publicdoublegetPrice(){returnbasePrice;}}OCP例-类6/6/202311Publicdoubletotalprice(Part[]parts){doubletotal=0.0;for(inti=0;i<parts.length;i++){total+=parts[i].getPrice();}returntotal;}OCP例-某类方法6/6/202312内存折扣?思考6/6/202313Publicdoubletotalprice(Part[]parts){doubletotal=0.0;for(inti=0;i<parts.length;i++){if(parts[I]instanceofMemory)total+=parts[i].getPrice()*0.9;elsetotal+=parts[i].getPrice();}returntotal;}方法6/6/202314符合OCP吗?思考6/6/202315PublicclassMemoryextendsPart{publicdoublegetPrice(){returnbasePrice*0.9;}}方法?6/6/202316采用一个PricePolicy类,通过对其进行继承以提供不同的计价策略更好的方法?6/6/202317PublicclassPart{privatePricePolicy

pricePolicy;publicvoidsetPricePolicy(PricePolicypolicy){

pricePolicy=policy;}publicvoidsetPrice(doubleprice){

pricePolicy.setPrice(price);}publicdoublegetPrice(){returnpricePolicy.getPrice();}}方法6/6/202318PublicclassPricePolicy{privatedoublebasePrice;publicvoidsetPrice(doubleprice){

basePrice=price;}publicdoublegetPrice(){returnbasePrice;}}价格策略6/6/202319PublicclassSaleextendsPricePolicy{privatedoublediscount;publicvoidsetDiscount(doublediscount){this.discount=discount;}publicdoublegetPrice(){returnbasePrice*discount;}}销售策略6/6/202320符合OCP了吗?思考6/6/202321应用实例我们有一个需要在标准的GUI上绘制园和正方形的应用程序。圆和正方形必须要按照特定的顺序绘制。我们将创建一个列表,列表由按照适当的顺序排列的园和正方形组成,程序遍历该列表,一次绘制出每个圆和正方形。6/6/202322先考虑违反OCP的过程化方法定义一个DrawAllShapes函数使用SWITCH来分支绘制图形为什么不符合OCP?因为它对于新的形状类型的添加不是封闭的每增加一种新的形状类型,都必须要更改这个函数6/6/202323这样的设计糟糕在哪里?增加形状会导致所有的程序、变量重新编译和部署想在另一个程序中复用DrawAllShape这个函数时,都必须要附带上Square和Circle,即时那个程序不需要它们。6/6/202324怎样遵循OCP编写一个shape抽象类这个类仅有一个抽象方法draw()所有形状都从这个类派生当绘制一种新的形状,只需要增加一个新的shape类的派生类。而DrawAllShapes

函数并不需要改变。6/6/202325使用指向基类(超类)的引用的函数,必须能够在不知道具体派生类(子类)对象类型的情况下使用它们。(FunctionTharUseReferenncesToBase(Super)ClassesMustBeAbleToUseObjectsOfDerived(Sub)ClassesWithoutKnowingIt)2.里氏替换法则6/6/202326PublicclassRectangle{privatedoublewidth;privatedoubleheigth;publicRectangle(doublew,doubleh){width=w;heigth=h;}publicvoidsetWidth(doublew){width=w;}publicvoidsetHeigth(doubleh){height=h;}publicdoublegetWidth(){returnwidth;}publicdoublegetHeigth(){returnheight;}publicdoublearea(){returnwidth*height;}}LSP例-矩形类6/6/202327正方形类Square正方形是矩形,因此Square类应该从Rectangle类派生而来。思考6/6/202328PublicclassSquareextendsRectangle{publicSquare(doubles){super(s,s);}publicvoidsetWidth(doublew){

super.setWidth(w);

super.setHeight(w);}publicvoidsetHeight(doubleh){

super.setWidth(h);

super.setHeight(h);}}正方形类6/6/202329PublicclassTestRectangle{publicstaticvoidtestLSP(Rectangler){r.setWidth(4.0);r.setHeight(5.0);

System.out.println(“Widthis4.0andHeightis5.0,Areais”+r.area());}测试类6/6/202330publicstaticvoidmain(Stringargs[]){Rectangler=newRectangle(1.0,1.0);Squares=newSquare(1.0);

testLSP(r);

testLSP(s);}}测试6/6/202331编写testLsp()方法的程序员做了一个合理的假设,即改变Rectangle的宽而保持它的高不变。一个数学意义上的正方形可能是一个矩形,但是一个Square对象不是一个Rectangle对象,因为一个Square对象的行为与一个Rectangle对象的行为是不一致的!(矩形仅包含get因为set不同)从行为上来说,一个Square不是一个Rectangle!一个Square对象与一个Rectangle对象之间不具有多态的特征。问题6/6/202332Liskov替换法则(LSP)清楚地表明了ISA关系全部都是与行为有关的。为了保持LSP,所有子类必须符合使用基类的client所期望的行为。一个子类型不得具有比基类型更多的限制,可能这对于基类型来说是合法的,但是可能会因为违背子类型的其中一个额外限制,从而违背了LSP!LSP保证一个子类总是能够被用在其基类可以出现的地方小结6/6/202333抽象不应当依赖于细节,细节应当依赖于抽象。(Abstationsshouldnotdependupondetails,Detailsshoulddependuponabstractions)3.依赖倒转原则6/6/202334针对接口编程,而非实现ProgramToAnInterface,NotAnImplementationDIP6/6/202335Client不必知道其使用对象的具体所属类。一个对象可以很容易地被(实现了相同接口的)的另一个对象所替换。对象间的连接不必硬绑定(hardwire)到一个具体类的对象上,因此增加了灵活性。松散藕合(loosenscoupling)。增加了重用的可能性。提高了(对象)组合的机率,因为被包含对象可以是任何实现了一个指定接口的类。

使用接口的优点6/6/202336不将变量声明为某个特定的具体类的实例对象,而让其遵从抽象类定义的接口。实现类仅实现接口,不添加方法。(Draw(shape*p)不要Cricle*pRectangle*pTriangle*p)针对接口编程6/6/202337任何变量都不应该持有一个指向具体类的指针或引用任何类都不应该从具体类派生任何方法都不应该覆写它的任何基类中已实现了的方法依赖于抽象6/6/202338如果一个类的实例必须使用另一个对象,而这个对象又属于一个特定的类,那么复用性会受到损害。如果“使用”类只需使用“被使用”类的某些方法,而不是要求“被使用”类与“使用”类有“is-a”的关系,就可考虑,让“被使用”类实现一个接口,“使用”类通过这个接口来使用需要的方法,从而限制了类之间的依赖。方案:为避免类之间因彼此使用而造成的耦合,让它们通过接口间接使用。约束6/6/202339DIP可应用于任何存在一个类向另一个类发送消息的地方。DIP应用6/6/202340例6/6/202341例-找出潜在的抽象6/6/202342实例考虑一个控制熔炉调节器的软件,该软件可以从一个IO通道中读取当前的温度,并通过向另一个IO通道发送命令来指示熔炉的开或者关。6/6/202343优先使用(对象)组合,而非(类)继承FavorCompositionOverInheritance4.组合复用原则6/6/202344容器类仅能通过被包含对象的接口来对其进行访问。“黑盒”复用,因为被包含对象的内部细节对外是不可见。封装性好。实现上的相互依赖性比较小。每一个类只专注于一项任务。通过获取指向其它的具有相同类型的对象引用,可以在运行期间动态地定义(对象的)组合。组合优点6/6/202345从而导致系统中的对象过多。为了能将多个不同的对象作为组合块(compositionblock)来使用,必须仔细地对接口进行定义。组合缺点6/6/202346(类)继承是一种通过扩展一个已有对象的实现,从而获得新功能的复用方法。泛化类(超类)可以显式地捕获那些公共的属性和方法。特殊类(子类)则通过附加属性和方法来进行实现的扩展继承6/6/202347容易进行新的实现,因为其大多数可继承而来。易于修改或扩展那些被复用的实现。继承优点6/6/202348破坏了封装性,因为这会将父类的实现细节暴露给子类。“白盒”复用,因为父类的内部细节对于子类而言通常是可见的。当父类的实现更改时,子类也不得不会随之更改。从父类继承来的实现将不能在运行期间进行改变。继承缺点6/6/202349仅当下列的所有标准被满足时,方可使用继承:子类表达了“是一个…的特殊类型”,而非“是一个由…所扮演的角色”。子类的一个实例永远不需要转化(transmute)为其它类的一个对象。子类是对其父类的职责(responsibility)进行扩展,而非重写或废除(nullify)。子类没有对那些仅作为一个工具类(utilityclass)的功能进行扩展。Coad规则6/6/202350例6/6/202351组合与继承都是重要的重用方法在OO开发的早期,继承被过度地使用随着时间的发展,我们发现优先使用组合可以获得重用性与简单性更佳的设计当然可以通过继承,以扩充可用的组合类集。因此组合与继承可以一起工作但是我们的基本法则是:优先使用对象组合,而非(类)继承小结6/6/202352LawofDemeter又称最少知识原则,一个对象应该对其他对象尽可能少的了解。5.迪米特法则(LoD)6/6/202353控制信息过载,提高封装能力。1. 创建弱耦合类,利于复用2. 降低成员访问权限3. 设计不变类广义6/6/202354如果两个类不必彼此通信,那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话,可通过第三者转发这个调用。狭义6/6/202355VoidSomeone::Operati

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论