Class Design Considerations Class stereotype Boundary Entity Control Applicable design patterns Architectural mechanisms Persistence Distribution etc. Object Oriented Analysis and Design 6
Object Oriented Analysis and Design 6 Class Design Considerations Class stereotype ▪ Boundary ▪ Entity ▪ Control Applicable design patterns Architectural mechanisms ▪ Persistence ▪ Distribution ▪ etc
How Many Classes Are Needed? Many,simple classes means that each class Encapsulates less of the overall system intelligence Is more reusable Is easier to implement A few,complex classes means that each class ■ Encapsulates a large portion of the overall system intelligence Is less likely to be reusable Is more difficult to implement A class should have a single well-focused purpose.A class should do one thing and do it well! Object Oriented Analysis and Design 7
Object Oriented Analysis and Design 7 A class should have a single well-focused purpose. A class should do one thing and do it well! How Many Classes Are Needed? Many, simple classes means that each class ▪ Encapsulates less of the overall system intelligence ▪ Is more reusable ▪ Is easier to implement A few, complex classes means that each class ▪ Encapsulates a large portion of the overall system intelligence ▪ Is less likely to be reusable ▪ Is more difficult to implement
Strategies for Designing Boundary Classes User interface (Ul)boundary classes ■ What user interface development tools will be used? How much of the interface can be created by the development tool? ◆ External system interface boundary classes Usually model as subsystem MainWindow SubWindow MainForm Button DropDownList Object Oriented Analysis and Design 8
Object Oriented Analysis and Design 8 Strategies for Designing Boundary Classes User interface (UI) boundary classes ▪ What user interface development tools will be used? ▪ How much of the interface can be created by the development tool? External system interface boundary classes ▪ Usually model as subsystem MainForm SubWindow Button DropDownList MainWindow
Strategies for Designing Entity Classes ◆ Entity objects are often passive and persistent Performance requirements may force some re-factoring ◆ See the Identify Persistent Classes step Analysis Design <Entity > FatClass FatClass -privateAttr privateAttr -commonlyUsedAttr1 getCommonlyUsedAttr1() commonlyUsedAttr2 getCommonlyUsedAttr2() rarelyUsed1 getRarelyUsedAtt1() -rarelyUsed2 getRarelyUsedAtt2() 0.1 FatClassDataHelper FatClassLazy DataHelper commonlyUsedAttr1 -rarelyUsedAttr1 commonlyUsedAttr2 rarelyUsedAttr2 Object Oriented Analysis and Design 9
Object Oriented Analysis and Design 9 Strategies for Designing Entity Classes Entity objects are often passive and persistent Performance requirements may force some re-factoring See the Identify Persistent Classes step Analysis FatClassLazyDataHelper - rarelyUsedAttr1 - rarelyUsedAttr2 Design FatClass - privateAttr + getCommonlyUsedAttr1() + getCommonlyUsedAttr2() + getRarelyUsedAtt1() + getRarelyUsedAtt2() FatClassDataHelper - commonlyUsedAttr1 - commonlyUsedAttr2 1 0..1 FatClass - privateAttr - commonlyUsedAttr1 - commonlyUsedAttr2 - rarelyUsed1 - rarelyUsed2 << Entity >>
Strategies for Designing Control Classes What happens to Control Classes? Are they really needed? Should they be split? ◆How do you decide? Complexity Change probability ■ Distribution and performance Transaction management Object Oriented Analysis and Design 10
Object Oriented Analysis and Design 10 Strategies for Designing Control Classes What happens to Control Classes? ▪ Are they really needed? ▪ Should they be split? How do you decide? ▪ Complexity ▪ Change probability ▪ Distribution and performance ▪ Transaction management