Class DesignAnother Look – Part 1.pptVIP

Class DesignAnother Look – Part 1 Note: there is so much more than below… More facts regarding Class DesignRe-look at Persistent ClassesRe-look at Class Operations Scope of OperationsMethodsStates – State ChartsAttributes Defining Dependenciesand Associations GeneralizationsMultiple InheritancePolymorphism We want to: Refine relationships, operations, and attributes 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. Address non- functional requirements We will look at Design patterns in the very near future. Class Design in Context* Recall: Entity Classes (1 of 3) Entity objects are often passive and persistent In Analysis, we identified entity classes. May have been associated with analysis mechanisms for persistence representing manipulated units of information. Performance concerns may suggest re-factoring of persistent classes, causing changes to the Design Model. (Re-factoring covered ahead) Maybe only ‘parts’ of objects need persistency…. Entity Classes - Sample of Re-factoring Have persistent class with five attributes. One attribute is not really persistent – used during runtime Use Cases tell us two attributes used a lot; two others less. In design, we would like to retrieve commonly used attributes right away but defer others until asked for. But we don’t want a complex design for the client. So: Entity Classes From a data standpoint, will consider the FatClass to be a proxy in front of the two real persistent data classes. It will retrieve FatClassDataHelper from database when it is first retrieved. Will retrieve FatClassLazyDataHelper in rare occasion when a client asks for one of these attributes. This is a view from a data-oriented perspective while retaining a logical object-oriented view for clients to use. It is tuning for performance too. Class Design Steps – Identify Persistent Classes In Us