ImageVerifierCode 换一换
格式:PPTX , 页数:25 ,大小:1.38MB ,
文档编号:5878007      下载积分:20 文币
快捷下载
登录下载
邮箱/手机:
温馨提示:
系统将以此处填写的邮箱或者手机号生成账号和密码,方便再次下载。 如填写123,账号和密码都是123。
支付方式: 支付宝    微信支付   
验证码:   换一换

优惠套餐
 

温馨提示:若手机下载失败,请复制以下地址【https://www.163wenku.com/d-5878007.html】到电脑浏览器->登陆(账号密码均为手机号或邮箱;不要扫码登陆)->重新下载(不再收费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  
下载须知

1: 试题类文档的标题没说有答案,则无答案;主观题也可能无答案。PPT的音视频可能无法播放。 请谨慎下单,一旦售出,概不退换。
2: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
3: 本文为用户(ziliao2023)主动上传,所有收益归该用户。163文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

1,本文(系统分析与设计IBM-43面向对象设计的原则课件.pptx)为本站会员(ziliao2023)主动上传,163文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。
2,用户下载本文档,所消耗的文币(积分)将全额增加到上传者的账号。
3, 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(发送邮件至3464097650@qq.com或直接QQ联系客服),我们立即给予删除!

系统分析与设计IBM-43面向对象设计的原则课件.pptx

1、关于对象设计关于对象设计你愿或者不愿,需求需求就在那里,日新月异你想或者不想,设计创新就在那里,始终持续始终持续 你测或者不测,BugBug都在那里,多多少少多多少少结束结束或者不结束,干系人在那里,决策决策终不由己来,面向对象的阵营里,或者,让对象思想驻对象思想驻进你的心里,默然,领会。由衷,欢喜关于对象设计关于对象设计其实,真相是:面向对象方法本身并不能保证你的设计成为优秀的设计You can create a very bad OO designjust as easily as you can create a very bad non-OO design.面向对象设计过程面向对象设计

2、过程 进行适当的领域分析 撰写问题描述,确定系统的开发任务 基于问题描述抽取需求 开发用户界面原型 识别对象类 定义每个类的职责 确定类之间的交互关系 建立系统的设计模型面向对象建模核心理念区分接口与实现从具体到抽象最小接口原则区分接口与实现区分接口与实现 接口的标准化 vs.实现的演化public void open(string name)/*some application-specific processing*/*call the Oracle API to open the DB*/*more application specific processing*/public void

3、 open(string name)/*some application-specific processing*/*call the SQLAnywhere to open the DB*/*more application specific processing*/接口 用户代码接口OracleDB2SQLAny用 户 代 码Using Abstract Thinking When Designing Interfaces设计抽象的接口抽象的接口抽象的接口抽抽 象象 的的 接接 口口师傅,请送我去机场师傅,请送我去机场不太抽象的接口不太抽象的接口不不 够够 抽抽 象象 的的 接接 口口右转

4、右转右转右转左转左转左转左转左转左转抽象的抽象的接 口:接 口:向向 用用 户户 暴暴 露露 尽尽 可可 能能 少少 的的 实实 现现 细细 节节 让用户知道的关于类的内部实现细节越少越好:只给看必须的 只看公开的 只为用户的业务需求考虑最最 小小 用用 户户 负负 担担 原原 则则确确 定定 用用 户户 用户是谁?重要程度高达50%面向服务的原则面向服务的原则 (Services Principle)提供服务提供服务:只要能赚钱就好只要能赚钱就好使使 用用 服服 务务:不要太贵喔不要太贵喔识别环境约束识别环境约束环境对对象的行为施加约束限制条件环境对对象的行为施加约束限制条件 前置条件前置条

5、件/后置条件后置条件/例外条件例外条件公共接口的识别公共接口的识别 用 户 使 用 出 租 车 对 象 的 时 候,需 要 以下功 能 告知司机终点付钱下 车 用 户 要 用 出 租 的 时 候:有出 行地点 召唤 出租 车 付钱确定实现细节确定实现细节 公共接口以外的内容都可以看做是实现相关的公共接口以外的内容都可以看做是实现相关的 用户永远无需关注实现细节方法的命名和参数定义(name and parameter list)编码实现 对实现的修改无须牵涉接 实现为用户的期望提供解决方案 接 口 从 用 户 的 角 度 看 待对象,实现则是对象的果核和果肉 实现中包含有描述对象状态的代码开闭

6、原则开闭原则(Open/Closed Principle,OCP)最初由Bertrand Meyer提出 软件实体在扩展性方面应该是开放的,而在更改性方面应该是 封闭 的。例:打印输出设计设计1设计2Liskov替换原则替换原则(Liskov Substitution Principle,LSP)最早由Liskov于1987年在OOPSLA会议上提出 子类可以替换父类出现在父类能出现的任何地方违反违反LSPLSP的例子的例子public class Rectangle private int topLe5X;private int topLe5Y;int width;int height;pu

7、blic 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方法??解决方法:解决方法:public class Square extends Rectangle public void setWidth(

8、int width)super.setWidth(width);super.setHeight(width);public void setHeight(int height)super.setHeight(height);super.setWidth(height);这种解决方法是否可行??考考 虑虑 下下 面面 的的 代代 码:码: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.

9、g(s);private void g(Rectangle r)r.setWidth(10);r.setHeight(20);assert(r.getWidth()*r.getHeight()=200);如果传给方法g的参数是Rectangle类型的对象,则没有问题,如果是Square类型的对象,则出错。?思考题:思考题:如如 何何 知知 道道 子子 类类 的的 行行 为为 符符 合合 父父 类类 的的 要要 求求?契约式设计(Design by Contract)为 了 满 足Liskov替换原则,设计时要求:子类中方法的前置条件不能强于父类中相应方法的前置条件。子类中方法的后置条件不能弱于

10、父类中相应方法的后置条件。Liskov 替换原则要求子类宽 入严出!依赖倒置原则依赖倒置原则(Dependency Inversion Principle,DIP)依赖倒置原则指的是依赖关系应该是尽量依赖接口(或抽象类),而不是依 赖于具体类。结构化设计中模块间的依赖关系面向对象设计中的依赖关系面向对象设计中的依赖关系OOD中的依赖关系接口分离原则接口分离原则(Interface Segrega:on Principle,ISP)在设计时采用多个和特定客户类(client)有关的接口要比采用一个通用的 接口要好。使用通用接口的设计使用分离接口的设计好的系统设计的特征 用 户 友 好 易理解 可靠 可扩展 可移植 可伸缩 可 重 用 简单性:实现简单,使 用 简 单,理 解 简 单,维 护 简 单软件老化的特征修改难很脆弱移植难重 用 难粘性强(设计+环境)需求变更OO设计时要注意的一些问题1.不同类中相似方法的名字应该相同2.遵守已有的约定俗成的习惯3.尽量减少消息模式的数目。只要可能,就使消息具有一致的模式,以利于理解。4.设计简单的类。类的职责要明确,应该从类名就可以较容易地推断出类的用途。5.定义简单的操作、方法6.定义简单的交互协议7.泛化结构的深度要适当8.把设计变动的副作用减至最少

侵权处理QQ:3464097650--上传资料QQ:3464097650

【声明】本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是网络空间服务平台,本站所有原创文档下载所得归上传人所有,如您发现上传作品侵犯了您的版权,请立刻联系我们并提供证据,我们将在3个工作日内予以改正。


163文库-Www.163Wenku.Com |网站地图|