资源预览内容
第1页 / 共25页
第2页 / 共25页
第3页 / 共25页
第4页 / 共25页
第5页 / 共25页
第6页 / 共25页
第7页 / 共25页
第8页 / 共25页
第9页 / 共25页
第10页 / 共25页
第11页 / 共25页
第12页 / 共25页
第13页 / 共25页
第14页 / 共25页
第15页 / 共25页
第16页 / 共25页
第17页 / 共25页
第18页 / 共25页
第19页 / 共25页
第20页 / 共25页
亲,该文档总共25页,到这儿已超出免费预览范围,如果喜欢就下载吧!
点击查看更多>>
资源描述
,4/7/2020,#,关于对象设计,你愿或者不愿,,需求,就在那里,,日新月异,你想或者不想,,设计创新,就在那里,,始终持续,你测或者不测,,Bug,都在那里,,多多少少,结束,或者不结束,干系人在那里,,决策,终不由己,来,面向对象的阵营里,,或者,让,对象思想驻,进你的心里,默然,领会。由衷,欢喜,关于对象设计你愿或者不愿,需求就在那里,日新月异,1,关于对象设计,其实,真相是:,面向对象方法本身并不能保证你的设计成为优秀的设计,You,can,create,a,very,bad OO design,just as easily as,you,can,create,a,very,bad,non-OO,design.,关于对象设计其实,真相是:,2,面向对象设计过程,进行适当的领域分析,撰写问题描述,确定系统的开发任务,基于问题描述抽取需求,开发用户界面原型,识别对象类,定义每个类的职责,确定类之间的交互关系,建立系统的设计模型,面向对象设计过程进行适当的领域分析,3,面向对象建模核心理念,区分接口与实现,从具体到抽象,最小接口原则,面向对象建模核心理念区分接口与实现,4,区分接口与实现,接口的标准化,vs.,实现的演化,public,void,open(string name),/*,some,application-specific,processing,*/,/*call,the,Oracle,API,to,open the,DB*/,/*,more application,specific,processing,*/,public,void,open(string name),/*,some,application-specific,processing,*/,/*call,the,SQLAnywhere,to,open the,DB*/,/*,more application,specific,processing,*/,区分接口与实现接口的标准化 vs.实现的演化,5,接口,用户代码,接口,Oracle,DB2,SQLA,n,y,用户代码,接口 用户代码接口OracleDB2SQLAny用户代码,6,Using Abstract Thinking,When,Designing,Interfaces,设计抽象的接口,Using Abstract Thinking When D,7,抽象的接口,抽,象,的,接,口,师傅,请送我去机场,抽象的接口抽 象 的 接 口师傅,请送我去机场,8,不太抽象的接口,不,够,抽,象,的,接,口,右转,右转,左转,左转,左转,不太抽象的接口不 够 抽 象 的 接 口,9,抽象的,接口:,向,用,户,暴,露,尽,可,能,少,的,实,现,细,节,让用户知道的关于类的内部实现细节越少越好,:,只给看必须的,只看公开的,只为用户的业务需求考虑,最,小,用,户,负,担,原,则,抽象的接口:向 用 户 暴 露,10,确,定,用,户,用户是谁?重要程度高达50%,面向服务的原则,(,Services,Principle,),提供服务,:,只要能赚钱就好,使,用,服,务,:,不要太贵喔,确 定 用 户用户是谁?重要程度高达50%提供服,11,识别环境约束,环境对对象的行为施加约束限制条件 前置条件,/,后置条件,/,例外条件,识别环境约束环境对对象的行为施加约束限制条件 前置条件/后置,12,公共接口的识别,用户,使,用,出,租,车,对,象,的,时,候,需,要 以下功,能,告知司机终点,付钱,下,车,用户,要,用,出,租,的时候,:,有出,行地点,召唤,出租,车,付钱,公共接口的识别用户 使 用 出 租 车 对 象 的,13,确定实现细节,公共接口以外的内容都可以看做是实现相关的,用户永远无需关注实现细节,方法的命名和参数定义,(name,and,parameter,list),编码实现,对实现,的修改无须牵涉接,实现为用户的期望提供解决方案,接口从用户的角度看待对象,,实现则是对象的果核和果肉,实现中包含有描述对象状态的代码,确定实现细节公共接口以外的内容都可以看做是实现相关的,14,开闭原则,(,Open/Closed,Principle,OCP,),最初由,Bertrand,Meyer,提出,软件实体在扩展性方面应该是开放的,,,而在更改性方面应该是,封闭,的,。,例:打印输出设计,设计1,设计2,开闭原则(Open/Closed Principle,OC,15,Liskov,替换原则,(Liskov,Substitution,Principle,LSP),最早由,Liskov,于,1987,年在,OOPSLA,会议上提出,子类可以替换父类出现在父类能出现的任何地方,Liskov替换原则(Liskov Substitutio,16,违反LSP的例子,public,class,Rectangle,private int,topLe5X;,private int,topLe5Y;,int,width;,int,height;,public,void,setWidth(int width),this.width,=,width;,public,void,setHeight(int,height),this.height,=,height;,public,int,getWidth(),return,width;,public,int getHeight(),return height;,问题:如果将,Square,作为,Rectangle,的子 类,则如何定义Square类的setWidth和,setHeight方法?,?,违反LSP的例子public class Rectangle,17,解决方法:,public,class,Square extends Rectangle,public,void,setWidth(int width),super.setWidth(width);,supe,r,.s,e,tHeig,h,t,(width);,public,void,setHeight(int,height),super.setHeight(height);super.setWidth(height);,这种解决方法是否可行,?,?,解决方法:public class Square exten,18,考,虑,下,面,的,代,码:,public,class,Test,public,staGc,void main(String,args),Test,t=,new,Test();,Rectangle,r=,new,Rectangle();,Square,s=,new,Square();,t.g(r);,/,t.g(s);,private,void g(Rectangle,r),r.setWidth(10);,r.setHeight(20);,assert,(r.getWidth()*r.getHeight(),=,200);,如果传给方法,g,的参数是,Rectangle,类型的对象,,,则没有问题,,,如果是,Square,类型的对象,,,则出错,。,?,考 虑 下 面 的 代 码:public class Tes,19,思考题:,如,何,知,道,子,类,的,行,为,符,合,父,类,的,要,求,?,契约式设计,(,Design,by Contract),为了满足,Liskov,替换原则,设计时要求:,子类中方法的前置条件不能强于父类中相应方法的前置条件,。,子类中方法的后置条件不能弱于父类中相应方法的后置条件,。,Liskov,替换原则要求子类宽,入严出,!,思考题:如 何 知 道 子 类 的 行 为 符 合 父,20,依赖倒置原则,(,Dependency Inversion,Principle,DIP),依赖倒置原则指的是依赖关系应该是尽量依赖接口(或抽象类),而不是依 赖于具体类。,结构化设计中模块间的依赖关系,依赖倒置原则(Dependency Inversion P,21,面向对象设计中的依赖关系,OO,D,中的依赖关系,面向对象设计中的依赖关系OOD中的依赖关系,22,接口分离原则,(,Interface,Segrega:on,Principle,ISP,),在设计时采用多个和特定客户类(,clien,t,)有关的接口要比采用一个通用的 接口要好。,使用通用接口的设计,使用分离接口的设计,接口分离原则(Interface Segrega:on Pr,23,好的系统设计的特征,用户友好,易理解,可靠,可扩展,可移植,可伸缩,可重用,简单性,:,实现简单,,,使,用简单,,,理解简单,,,维护简单,软件老化的特征,修改难,很脆弱,移植难,重,用难,粘性强,(设计,+,环境,),需求变更,好的系统设计的特征用户友好简单性:实现简单,使 用简单,理解,24,O,O,设计时要注意的一些问题,不同类中相似方法的名字应该相同,遵守已有的约定俗成的习惯,尽量减少消息模式的数目,。,只要可能,,,就使消息具有一致的模式,,,以利于理解,。,设计简单的类,。,类的职责要明确,,,应该从类名就可以较容易地推断出类的用途,。,定义简单的操作,、,方法,定义简单的交互协议,泛化结构的深度要适当,把设计变动的副作用减至最少,OO设计时要注意的一些问题不同类中相似方法的名字应该相同,25,
点击显示更多内容>>

最新DOC

最新PPT

最新RAR

收藏 下载该资源
网站客服QQ:3392350380
装配图网版权所有
苏ICP备12009002号-6