- 1、本文档共20页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
第五章设计准则2-灵活性和可重用性讲述
设计准则II灵活性、可重用性和高效性
灵活性
在设计时通常要考虑到将来的变化
… 增加更多相同类型功能
例如 (银行应用):处理更多类型的帐号,不需要修改已存在的设计或代码
… 增加不同的功能
例如: 在存款的基础增加提款功能
… 修改功能
例如: 允许透支
WebSite
register()
Member
0..n
members
网站成员注册
Class Website
{
Member[] members; // or maybe: Vector member;
void register( Member aMember ) { . . . }
}
网站成员注册
WebSite
Member
0..n
StandardMember
XMember
YMember
members
引入基类,并抽象化
灵活性
增加新功能要依据其上下文和应用范围
在以下范围内:
一系列相关的函数
例如:在航空旅行线路(travel itinerary)的函数中增加打印功能
一个已存在的基类
例如: 在航空路线中增加“打印公路和轮船”的功能
两者都不是
例如: 增加“打印航空、公路、轮船混合路线”的功能
情况2:向一个基类中增加功能
Trip
printItinerary()
StandardTrip
printItinerary()
SomeApplicationClass
Method(s) call
printItinerary()
通过继承基类的方法来增加功能
Trip
printItinerary()
SeaTrip
printItinerary()
SomeApplicationClass
LandTrip
printItinerary()
StandardTrip
printItinerary()
可重用性
一个方法相对于上下文环境越独立,其可重用性就越高。
可重用性
完全指定
详细说明前置条件、后置条件等
避免不必要的封装类耦合
如果可行,让方法成为静态的
参数化
例如,让方法功能化
但限制参数的个数
让名字更具有表达性
可理解性促进了可重用性
解释算法
重用者需要知道算法是如何工作的
基于重用的类选择
完整地描述类
使类名和功能与实际情况相符
定义一个有用的抽象类
以获得更广泛的适用性
减少对其他类的依赖性
通过继承获得
可选
高效性
应用程序必须在指定的时间内完成特定的功能,同样,对内存容量也有一定的要求。
高效性
先按其他原则设计,再考虑效率问题
以灵活性、可重用性等原则进行设计
找出效率低的部分
有针对性地修改
一开始就按效率原则进行设计
确认当前关键的效率需求
在整个阶段都按需求进行设计
以上两种方法的结合
在设计时为效率需求作出折中
在初始设计后,也要继续考虑效率问题
执行效率
实时系统对执行速度要求很高,要求在固定的时间内完成所需的功能,通常以微秒级进行计算(衡量)。
即使是非实时系统,执行速度也很重要
执行效率
实时系统对执行速度要求很高,要求在固定的时间内完成所需的功能,通常以微秒级进行计算(衡量)。
即使是非实时系统,执行速度也很重要
引起执行效率问题的一些因素
循环
While、for、do
远程调用
需要网络
LAN
Internet
函数调用
如果函数调用导致以上情况发生
对象创建
存储效率
只存储需要的数据
在存储效率与数据提取及重整时间之间获得折中
压缩数据
在存储效率与数据压缩及解压缩时间之间获得折中
按相关访问频率存储数据
在存储效率与决定存储位置的时间之间获得折中
健壮性、灵活性、可重用性与高效性之间的折中
极限编程法
或完全为效率而设计
灵活性驱动法
着眼于将来的需求 附带考虑可重用性
确保健壮性
提供足够高的效率
如果为了获得在效率方面的需求,那么会在可重用性方面作出折中
极限编程法vs非极限编程法
+ 工作完成迅速(通常)
+ 范围清晰
+ 可能更有效
-----------------------------
- 未来应用可能较少用到
- 扩展需求代价很大
+ 未来应用可能较多用到
+ 需求可变
-----------------------------
- 范围划分不清晰
- 可能会比较费力
- 需要更多地关注效率
一个更灵活的计算器应用程序的设计
CommandLineCalculator
main()
executeAdditions()
solicitNumberAccounts()
getAnInputFromUser()
interactWithUser()
已存在的设计
新的设计
Calculator
solicitNumAccounts()
CalcDisplay
display()
CalcOpe
文档评论(0)