150 likes | 159 Views
OOD - Principles Design Class Diagrams. Chapter 12. Domain Class vs. Design Class. Design Class: Things to Know. Attributes Elaborate attributes Methods Method types Method Signatures Instance Level & Class Level (attributes & methods). Elaborating Attributes.
E N D
OOD - Principles Design Class Diagrams Chapter 12
Design Class: Things to Know • Attributes • Elaborate attributes • Methods • Method types • Method Signatures • Instance Level & Class Level (attributes & methods)
Elaborating Attributes visibilityattributeName: dataType {property} • Visibility • Public or Private • Data type • Numbers: integer, double • Text: string • True/False: boolean • Dates: dateTime • Property • key
Method Types • 3 Method types • Constructor methods • Accessor methods • Get • Set • Processing methods
Method Signatures visibilitymethodName(parameterList) : returnType • Visibility • Public or Private • Method name • Verb phrase • Parameter List • Inputs • Return Type • Output • Typical data type: integer, string, etc • Object (e.g. Student) • Collection of objects: StudentArray
Instance-Level vs. Class-Level Attributes & Methods • Instance-Level • Pertains to an individual object/instance • Attribute name • Method getName(), calcGPA() • Class-Level • Does not pertain to an individual object/instance • Attribute tuitionPerHour • Method findAboveHours() -tuitionPerHour: integer
Exercise • Design a Design Class for: Vehicle • Attributes • Primary Key • Instance attribute • Class Attribute • Method • Constructor method • Instance Method • Accessor methods (2) • Processing method • Class Method
Design Class Diagram Overridden Method How many attributes are there in a MailOrder object?
Fundamental Design Principles • Object Responsibility • Separation of Responsibilities • Protection from Variations • Indirection • Coupling - low • Cohesion - high
Fundamental Design Principles • Object Responsibility - objects are responsible for carrying out system processing • “Knowing” - attributes & associations • “Doing” - carrying out methods (i.e. doing what they are asked to do)
Fundamental Design Principles • Separation of Responsibilities - Separation of Concerns • Segregate classes into groups • Protection from Variations - parts of a system unlikely to change are separated (protected) from those that will surely change • e.g. Separate UI forms that are likely to change from application logic • e.g. Put DB connection & SQL statements that are likely to change in a separate classes from application logic 3-Layer Design
Fundamental Design Principles • Coupling- how closely related classes are linked (tightly or loosely coupled) • Two classes are tightly coupled if: • there are lots of associations with another class • there are lots of messages to another class • e.g. a customer object can access a Sale object this coupling is necessary • e.g. a customer object can access a SaleItem object this coupling is not • Cohesion– a measure of the focus or unity of purpose within a single class • A class has high cohesiveness if: • all of its responsibilities are consistent & make sense for purpose of the class • e.g. a customer object carries out responsibilities that naturally apply to customers • A class has low cohesiveness if: • its responsibilities are broad • e.g. a customer object requests a new order but also requests that inventory be updated.
Fundamental Design Principles • Indirection - an intermediate class should be placed between 2 classes to decouple them but still link them • e.g. Add a controller class between UI classes and problem domain classes