ITM305 Week 9 - Fundamental Design Principles PDF

# Week 9 ## Fundamental Design Principles ### Object Responsibility * States objects are responsible for carrying out system processing * **Fundamental assumption of design and programming:** "Knowing" and "doing" * **Objects know how to carry out methods, and do what they are asked to do** ###...

# Week 9 ## Fundamental Design Principles ### Object Responsibility * States objects are responsible for carrying out system processing * **Fundamental assumption of design and programming:** "Knowing" and "doing" * **Objects know how to carry out methods, and do what they are asked to do** ### Separation of Responsibility (Separation of concerns) * Applied to a group of classes * **Segregated classes into packages or groups** ### Protection from variations * **Design principle that states parts of a system unlikely to change are separated (protected) from those that will surely change** * Separate user interface forms and pages that are likely to change from application logic * Put database connection and SQL logic that is likely to change in a separate classes from application logic ### Coupling * **Quantitative measure of how closely related classes are linked (tightly or loosely coupled)** * Two classes are tightly coupled of there are lots of associations with another class * Two classes are tightly coupled if there are lots of messages to another class. It is best to have classes that are loosely coupled * If deciding between two alternative designs, choose the one where overall coupling is less ### Cohesion * **A quantitative measure of the focus or unity of purpose within a single class (high or low cohesiveness** * One class has high cohesiveness if all of its responsibilities are consistent and make sense for the purpose of the class. (a customer carries out responsibilities that naturally apply to customers) * One class has low cohesiveness if its responsibilities are broad or makeshift * It is best to have classes that are **highly cohesive**. * If deciding between two alternative designs, choose the one where overall cohesiveness is high ### Encapsulation * Bundling of data, along with the methods that operate on that data, into a single unit. Used to hide both data members and data functions or methods associated with an instantiated class or object. * **A benefit of encapsulation is that it can reduce system complexity, and thus increase robustness, by allowing the developer to limit the interdependencies between software components** ### Inheritance * It is a mechanism where you can derive a class from another class for a hierarchy of classes that share a set of attributes and methods. * With inheritance, it is not necessary to redefine the inherited attributes and methods of the existing class. * The parent class is called a **super class**. * The inherited class is called a **subclass**. ### Indirection * A design principle that states an intermediate class is placed between two classes to decouple them but still link them * A controller class between UI classes and problem domain classes is an example * Supports low coupling * Indirection is used to support security by directing messages to an intermediate class as in a firewall * If deciding between two alternative designs, choose the one where indirection reduces coupling or provides greater security ### Polymorphism * Allows implementation of multiple methods within the same class that use the same name but with a different set of parameters (either by number and/or type). * Used a lot with the "Constructor" method that creates and initial instance of a class in memory * Due to the different sets of parameters, each method has a different signature. ### Use base Controller * Switchboard between user-interface classes and domain layer classes * Reduces coupling between view and domain layer * A controller can be created for each use case, however, several controllers can be combined together for a group of related use cases * It is a completely artificial class - an artifact ### Understanding Sequence Diagrams * **Lifeline** * The dashed line under the object which serves as an origin point and a destination point for messages * **Activation lifeline** * The vertical box on a lifeline which indicates the time period when the object is executing based on the message * Messages have origins and destinations * May be on lifeline or on object box * Return values may be dashed message arrow, or on same message ### OOD with Sequence Diagrams * Choose a use case * Input models - activity diagram, SSD, classes * Create first-cut DCD * Extend input messages * Add all required internal messages * Origin and destination objects * Elaborate each message * Update DCD ### Guidelines * From each input message * Determine all internal messages * Determine all objects (from classes) as origins or destinations * Flesh out each message with true/false conditions, parameters and returned values ### Assumptions * Perfect technology assumption * No logon or other technical issues * Perfect solution assumption * No exception conditions, no error handling