Class DesignAnother Look – Part 1

上传人:洪易 文档编号:2671220 上传时间:2017-08-06 格式:PPT 页数:44 大小:373.50KB
返回 下载 相关 举报
Class DesignAnother Look – Part 1_第1页
第1页 / 共44页
Class DesignAnother Look – Part 1_第2页
第2页 / 共44页
Class DesignAnother Look – Part 1_第3页
第3页 / 共44页
Class DesignAnother Look – Part 1_第4页
第4页 / 共44页
Class DesignAnother Look – Part 1_第5页
第5页 / 共44页
点击查看更多>>
资源描述

《Class DesignAnother Look – Part 1》由会员分享,可在线阅读,更多相关《Class DesignAnother Look – Part 1(44页珍藏版)》请在金锄头文库上搜索。

1、Class DesignAnother Look Part 1Note: there is so much more than belowo More facts regarding Class DesignRe-look at Persistent ClassesRe-look at Class Operationso Scope of OperationsMethodsStates State ChartsAttributeso Defining Dependenciesand Associationso GeneralizationsMultiple InheritancePolymor

2、phismWe want to:o Refine relationships, operations, and attributeso Focus on fleshing out the details of a particular class operations needed and allocated to classes and how they collaborate to support the responsibilities allocated to the class. o Address non- functional requirementso We will look

3、 at Design patterns in the very near future.Class Design in Context*ArchitectDesignerArchitecturalAnalysisArchitectureReviewerReview theDesignReview theArchitectureUse-CaseAnalysisArchitecturalDesignDescribeConcurrencyDescribeDistributionClassDesignSubsystem DesignUse-CaseDesign DesignReviewerThis i

4、s where we stand. Recall:Architectural Design is where we decide what the infrastructure is (pieces and parts of the architecture and how they interact). Use Case Design is where the responsibilities of the system are allocated to the pieces/parts; Subsystem and Class design are where we detail the

5、specifics of the pieces/parts.Class Design in Context*ArchitectDesignerArchitecturalAnalysisArchitectureReviewerReview theDesignReview theArchitectureUse-CaseAnalysisArchitecturalDesignDescribeConcurrencyDescribeDistributionClass DesignSubsystem DesignUse-CaseDesign DesignReviewerDuring Class Design

6、, we consider: implementation and deployment environments. May need to adjust the classes to the particular products in use, the programming languages, distribution, performance, use of component architectures like COM or CORBA, and other constraints Frequent iteration between Class Design, Subsyste

7、m Design and Use Case Design. Class Design - performed for each class in current iteration.A class should have a single well focused purpose.A class should do one thing and do it well!How Many Classes Are Needed? o Many, simple classes means that each class n Encapsulates less of the overall system

8、intelligencen Is more reusablen Is easier to implemento Few, complex classes means that each classn Encapsulates a large portion of the overall system intelligencen Is less likely to be reusablen Is more difficult to implemento Proper size may depend heavily on implementation environment classes sho

9、uld map directly to some phenomenon in the implementation language in such a way that the mapping results in good code.MainFormSubWindowDropDownListButtonMainWindowRecall: Boundary Classes External System Interface:*o Note:n Usually model as subsystem (recall Billing System interface?)n Oftentimes t

10、hese interfaces have complex internal behavior (hence the modeling as a subsystem)Recall: Entity Classes (1 of 3)o Entity objects are often passive and persistento In Analysis, we identified entity classes. n May have been associated with analysis mechanisms for persistence representing manipulated

11、units of information.n Performance concerns may suggest re-factoring of persistent classes, causing changes to the Design Model. (Re-factoring covered ahead)o Maybe only parts of objects need persistency.Analysis DesignFatClass- transientBookeeping+ getCommonlyUsedAtt1()+ getCommonlyUsedAtt2()+ getR

12、arelyUsedAtt3()+ getRarelyUsedAtt4()FatClassDataHelper+ commonlyUsedAtt1+ commonlyUsedAtt2FatClassLazyDataHelper+ rarelyUsedAtt3+ rarelyUsedAtt41 1FatClass- transientBookeeping+ commonlyUsedAtt1+ commonlyUsedAtt2+ rarelyUsedAtt3+ rarelyUsedAtt4Entity Classes - Sample of Re-factoringo Have persistent

13、 class with five attributes.o One attribute is not really persistent used during runtime o Use Cases tell us two attributes used a lot; two others less.o In design, we would like to retrieve commonly used attributes right away but defer others until asked for. n But we dont want a complex design for

14、 the client. n So:Analysis DesignFatClass- transientBookeeping+ getCommonlyUsedAtt1()+ getCommonlyUsedAtt2()+ getRarelyUsedAtt3()+ getRarelyUsedAtt4()FatClassDataHelper+ commonlyUsedAtt1+ commonlyUsedAtt2FatClassLazyDataHelper+ rarelyUsedAtt3+ rarelyUsedAtt41 1FatClass- transientBookeeping+ commonly

15、UsedAtt1+ commonlyUsedAtt2+ rarelyUsedAtt3+ rarelyUsedAtt4Entity Classeso From a data standpoint, will consider the FatClass to be a proxy in front of the two real persistent data classes.o It will retrieve FatClassDataHelper from database when it is first retrieved. Will retrieve FatClassLazyDataHe

16、lper in rare occasion when a client asks for one of these attributes.o This is a view from a data-oriented perspective while retaining a logical object-oriented view for clients to use.o It is tuning for performance too.So, which would you ratherretrieve? FatClass or FatClassDataHelper?Recall: Control Classeso What Happens to Control Classes?n Are they really needed? Spl

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 商业/管理/HR > 管理学资料

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号