面向对象from teacher设计原则

2/15/20231提高面向对象设计复用性的设计原则面向对象的设计原则2/15/20232设计目标可扩展性(Extensibility):新功能易加入系统。灵活性(Flexibility):允许代码修改平稳发生，不会涉及很多其他模块。可插入性(Pluggability):容易将一个类换为另一个具有同样接口的类。2/15/20233软件复用重要性较高的生产率较高的软件质量恰当使用复用,可改善系统的可维护性2/15/20234使一个系统可在更高的层次上提供了可复用性抽象化和继承:使概念和定义可复用多态:使实现和应用可复用抽象化和封装:可保持和促进系统的可维护性面向对象设计2/15/20235抽象层次是一个应用系统作战略性判断和决定的地方，那么抽象层次就应当是较为稳定的，应当是复用的重点。复用的焦点不再集中在函数和算法等具体实现细节上，而是集中在最重要的含有宏观商业逻辑的抽象层次上。既然如果抽象层次的模块相对独立于具体层次的模块的话，那么具体层次内部的变化就不会影响到抽象层次的结构，所以抽象层次的复用就会较为容易。复用2/15/20236面向对象设计中，可维护性复用是以设计原则和设计模式为基础的。面向对象复用2/15/202371.开闭原则OCP:Open-ClosedPrinciple2. 里氏替换原则LSP:LiskovSubstitutionPrinciple3. 依赖倒转原则DIP:DependencyInversionPrinciple4. 接口隔离原则ISP:InterfaceSegregationPrinciple5. 组合复用原则positoinResusePrinciple6. 迪米特法则LoD:LawofDemeter7.单一职责原则（SRP)面向对象设计原则2/15/20238软件组成实体应该是对扩展开放的，但是对修改是关闭的。(SoftwareEntitiesShouldBeOpenForExtension，ButClosedForModification)1988年，勃兰特·梅耶（BertrandMeyer）在他的著作《面向对象软件构造（ObjectOrientedSoftwareConstruction）》中提出1.开-闭原则OCP2/15/20239这句话说得略微有点专业，我们把它讲得更通俗一点，也就是：软件系统中包含的各种组件，例如模块（Modules）、类（Classes）以及函数（Functions）等等，应该在不修改现有代码的基础上，引入新功能。“开”，是允许对其进行功能扩展的；“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。2/15/202310在设计一个软件的时候，应当使这个软件可以在不被修改的前提下扩展已有模块，尤其是最重要的抽象层模块不能动：保证稳定性和延续性可以扩展新模块：增加新行为，保证灵活性2/15/202311开-闭法则认为应该试图去设计出永远也不需要改变的模块。关键在于抽象化:可给系统定义一个一劳永逸，不再更改的抽象设计，此设计允许有无穷无尽的行为在实现层被实现。抽象层可以允许、支持所有扩展。PC外设开-闭原则2/15/202312优点可复用性好：提高适应性、灵活性我们可以在软件完成以后，仍然可以对软件进行扩展，加入新的功能，非常灵活。因此，这个软件系统就可以通过不断地增加新的组件，来满足不断变化的需求。可维护性好：由于对于已有的软件系统的组件，特别是它的抽象底层不去修改，因此，我们不用担心软件系统中原有组件的稳定性，这就使变化中的软件系统有一定的稳定性和延续性。2/15/202313玉帝遵照“开-闭”原则维护天庭秩序当年孙悟空大闹天空，向天庭发出挑战：“皇帝轮流做，明年到我家......只教他搬出去，将天宫让与我！”太白金星给玉皇大帝 建议道：“降一道招安 圣旨，把他宣来上界...

与他籍名在箓...

一则不动众劳师， 二则收仙有道也。”2/15/2023142/15/202315“封装可变性原则”gof：“考虑你的设计中什么可能会发生变化......考虑你允许什么发生变化而不让这一变化导致重新设计”Shalloway：“发现变化点，并封装之”一种可变性不应散落在代码的很多角落一种可变性不应当与另一种可变性混合在一起2/15/202316一个软件系统的所有模块不可能都满足OCP，但是应该努力最小化这些不满足OCP的模块数量。开-闭原则2/15/202317PublicclassPart{privatedoublebasePrice;publicvoidsetPrice(doubleprice){basePrice=price;}publicdoublegetPrice(){returnbasePrice;}}OCP例-类2/15/202318Publicdoubletotalprice(Part[]parts){doubletotal=0.0;for(inti=0;i<parts.length;i++){total+=parts[i].getPrice();}returntotal;}OCP例-某类方法2/15/202319内存折扣？思考2/15/202320Publicdoubletotalprice(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;}方法2/15/202321符合OCP吗？思考2/15/202322PublicclassMemoryextendsPart{publicdoublegetPrice(){returnbasePrice*0.9;}}方法？2/15/202323采用一个PricePolicy类，通过对其进行继承以提供不同的计价策略更好的方法？2/15/202324PublicclassPart{privatePricePolicypricePolicy;publicvoidsetPricePolicy(PricePolicypolicy){pricePolicy=policy;}publicvoidsetPrice(doubleprice){pricePolicy.setPrice(price);}publicdoublegetPrice(){returnpricePolicy.getPrice();}}方法2/15/202325PublicclassPricePolicy{privatedoublebasePrice;publicvoidsetPrice(doubleprice){basePrice=price;}publicdoublegetPrice(){returnbasePrice;}}价格策略2/15/202326PublicclassSaleextendsPricePolicy{privatedoublediscount;publicvoidsetDiscount(doublediscount){this.discount=discount;}publicdoublegetPrice(){returnbasePrice*discount;}}销售策略2/15/202327符合OCP了吗？思考2/15/202328应用实例我们有一个需要在标准的GUI上绘制园和正方形的应用程序。圆和正方形必须要按照特定的顺序绘制。我们将创建一个列表，列表由按照适当的顺序排列的园和正方形组成，程序遍历该列表，一次绘制出每个圆和正方形。2/15/202329先考虑违反OCP的过程化方法定义一个DrawAllShapes函数使用SWITCH来分支绘制图形为什么不符合OCP？因为它对于新的形状类型的添加不是封闭的每增加一种新的形状类型，都必须要更改这个函数2/15/202330这样的设计糟糕在哪里？增加形状会导致所有的程序、变量重新编译和部署想在另一个程序中复用DrawAllShape这个函数时，都必须要附带上Square和Circle，即时那个程序不需要它们。2/15/202331怎样遵循OCP编写一个shape抽象类这个类仅有一个抽象方法draw()所有形状都从这个类派生当绘制一种新的形状，只需要增加一个新的shape类的派生类。而DrawAllShapes函数并不需要改变。2/15/202332使用指向基类(超类)的引用的函数，必须能够在不知道具体派生类(子类)对象类型的情况下使用它们。(FunctionTharUseReferenncesToBase(Super)ClassesMustBeAbleToUseObjectsOfDerived(Sub)ClassesWithoutKnowingIt)2.里氏替换法则2/15/202333一个软件如果使用的是一个父类的话，如果把该父类换成子类，它不能察觉出父类对象和子类对象的区别也就是凡是父类适用的地方子类也适用继承只有满足里氏代换原则才是合理的2/15/2023342/15/202335墨子论“取譬”“白马，马也；乘白马，乘马也。骊马，马也；乘骊马，乘马也。”解释：白马、骊马(黑马)都是马，既然马可以骑，那么白马和骊马肯定也可以骑2/15/202336反过来的代换不成立子类适用的地方不要求父类一定能适用墨子又说“娣，美人也，爱娣，非爱美人也......盗，人也，恶盗，非恶人也”妹妹是美女，哥哥喜欢妹妹，并不是因为喜欢美女小偷是人，讨厌小偷，并不讨厌所有人2/15/202337PublicclassRectangle{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例-矩形类2/15/202338正方形类Square正方形是矩形，因此Square类应该从Rectangle类派生而来。思考2/15/202339PublicclassSquareextendsRectangle{publicSquare(doubles){super(s,s);}publicvoidsetWidth(doublew){super.setWidth(w);super.setHeight(w);}publicvoidsetHeight(doubleh){super.setWidth(h);super.setHeight(h);}}正方形类2/15/202340PublicclassTestRectangle{publicstaticvoidtestLSP(Rectangler){r.setWidth(4.0);r.setHeight(5.0);System.out.println(“Widthis4.0andHeightis5.0,Areais”+r.area());}测试类2/15/202341publicstaticvoidmain(Stringargs[]){Rectangler=newRectangle(1.0,1.0);Squares=newSquare(1.0);

testLSP(r);testLSP(s);}}测试2/15/202342编写testLsp()方法的程序员做了一个合理的假设，即改变Rectangle的宽而保持它的高不变。一个数学意义上的正方形可能是一个矩形，但是一个Square对象不是一个Rectangle对象，因为一个Square对象的行为与一个Rectangle对象的行为是不一致的！(矩形仅包含get因为set不同)从行为上来说，一个Square不是一个Rectangle！一个Square对象与一个Rectangle对象之间不具有多态的特征。问题2/15/2023432/15/202344Liskov替换法则(LSP)清楚地表明了ISA关系全部都是与行为有关的。为了保持LSP，所有子类必须符合使用基类的client所期望的行为。一个子类型不得具有比基类型更多的限制，可能这对于基类型来说是合法的，但是可能会因为违背子类型的其中一个额外限制，从而违背了LSP！LSP保证一个子类总是能够被用在其基类可以出现的地方小结2/15/202345抽象不应当依赖于细节，细节应当依赖于抽象。(Abstationsshouldnotdependupondetails，Detailsshoulddependuponabstractions)3.依赖倒转原则2/15/20234646设计原则：依赖倒置原则为什么说“倒置”传统的设计是抽象层依赖具体层传统的重用，侧重于具体层次的模块，比如算法、数据结构、函数库因此软件的高层模块依赖低层模块传统的依赖方向2/15/20234747设计原则：依赖倒置原则高层依赖低层的问题抽象层包含的是系统的业务逻辑和宏观的、战略性的决定，是必然性的体现具体层则含有与实现相关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。具体层经常有变动，难免出现错误必然依赖偶然，稳定依赖变动？2/15/20234848设计原则：针对接口编程如何做到“依赖倒置”？“Programtoaninterface,notanimplementation”设计原则：针对接口编程要针对接口编程不要针对实现编程2/15/20234949设计原则：针对接口编程“针对接口编程”的一些建议变量、参数、返回值等应声明为抽象类不要继承非抽象类不要重载父类的非抽象方法当然这些只是建议实际情况要权衡利弊2/15/202350不将变量声明为某个特定的具体类的实例对象，而让其遵从抽象类定义的接口。实现类仅实现接口，不添加方法。(Draw(shape*p)不要Cricle*pRectangle*pTriangle*p)针对接口编程2/15/202351任何变量都不应该持有一个指向具体类的指针或引用任何类都不应该从具体类派生任何方法都不应该覆写它的任何基类中已实现了的方法依赖于抽象2/15/202352Client不必知道其使用对象的具体所属类。一个对象可以很容易地被(实现了相同接口的)的另一个对象所替换。对象间的连接不必硬绑定(hardwire)到一个具体类的对象上，因此增加了灵活性。松散耦合(loosenscoupling)。增加了重用的可能性。提高了(对象)组合的机率，因为被包含对象可以是任何实现了一个指定接口的类。使用接口的优点2/15/202353如果一个类的实例必须使用另一个对象，而这个对象又属于一个特定的类，那么复用性会受到损害。如果“使用”类只需使用“被使用”类的某些方法，而不是要求“被使用”类与“使用”类有“is-a”的关系，就可考虑，让“被使用”类实现一个接口，“使用”类通过这个接口来使用需要的方法，从而限制了类之间的依赖。方案:为避免类之间因彼此使用而造成的耦合，让它们通过接口间接使用。约束2/15/202354DIP可应用于任何存在一个类向另一个类发送消息的地方。DIP应用2/15/202355例2/15/202356例-找出潜在的抽象2/15/202357优先使用(对象)组合，而非(类)继承FavorCompositionOverInheritance4.组合复用原则2/15/202358容器类仅能通过被包含对象的接口来对其进行访问。“黑盒”复用，因为被包含对象的内部细节对外是不可见。封装性好。实现上的相互依赖性比较小。每一个类只专注于一项任务。通过获取指向其它的具有相同类型的对象引用，可以在运行期间动态地定义(对象的)组合。组合优点2/15/202359从而导致系统中的对象过多。为了能将多个不同的对象作为组合块(compositionblock)来使用，必须仔细地对接口进行定义。组合缺点2/15/202360(类)继承是一种通过扩展一个已有对象的实现，从而获得新功能的复用方法。泛化类(超类)可以显式地捕获那些公共的属性和方法。特殊类(子类)则通过附加属性和方法来进行实现的扩展继承2/15/202361容易进行新的实现，因为其大多数可继承而来。易于修改或扩展那些被复用的实现。继承优点2/15/202362破坏了封装性，因为这会将父类的实现细节暴露给子类。“白盒”复用，因为父类的内部细节对于子类而言通常是可见的。当父类的实现更改时，子类也不得不会随之更改。从父类继承来的实现将不能在运行期间进行改变。继承缺点2/15/202363仅当下列的所有标准被满足时，方可使用继承：子类表达了“是一个…的特殊类型”，而非“是一个由…所扮演的角色”。子类的一个实例永远不需要转化(transmute)为其它类的一个对象。子类是对其父类的职责(responsibility)进行扩展，而非重写或废除(nullify)。子类没有对那些仅作为一个工具类(utilityclass)的功能进行扩展。Coad规则2/15/202364例2/15/202365组合与继承都是重要的重用方法在OO开发的早期，继承被过度地使用随着时间的发展，我们发现优先使用组合可以获得重用性与简单性更佳的设计当然可以通过继承，以扩充可用的组合类集。因此组合与继承可以一起工作但是我们的基本法则是：优先使用对象组合，而非(类)继承小结2/15/202366LawofDemeter又称最少知识原则，一个对象应该对其他对象尽可能少的了解。5.迪米特法则(LoD)2/15/202367控制信息过载，提高封装能力。1. 创建弱耦合类，利于复用2. 降低成员访问权限3. 设计不变类广义2/15/202368如果两个类不必彼此通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可通过第三者转发这个调用。狭义2/15/202369朋友圈2/15/2023702/15/202371VoidSomeone::Operation1(Friendfriend){Strangerstranger=vide();stranger.Operation3();}StrangerFriend::provide(){returnstr