Design Ch 8 and Ch 12 Dan Fleck

Design (Ch 8 and Ch 12) Dan Fleck CS 421 George Mason University Coming up: What is the design phase?

What is the design phase? • Analysis phase describes what the system should do • Analysis has provided a collection of classes and descriptions of the scenarios that the objects will be involved in. These functions are clustered in groups with related behavior. • The design phase is to work out how the system should do these things. This is the goal of the design phase. Coming up: Analysis --> Design

Analysis --> Design Coming up: Analysis --> Design

Analysis --> Design Coming up: Analysis --> Design

Analysis --> Design Coming up: Analysis --> Design

Analysis --> Design Coming up: Oversimplification

Oversimplification Analysis Design Classes Attributes Operations Relationships Behavior Objects Data Structures Algorithms Messaging Control Coming up: The Design Spec

Architecture Design - The Design Spec • Layers of the software (e. g. model, view, controller (MVC)) • Categories of classes (e. g. UI, Business logic, interfaces) Component design • Description of classes/methods/algorithms • State machines for classes • (Think: individual classes) UI design • sample screens • UI guidelines/standards we’re using • detailed description of how UI components work Data design • database design • data structures we’re using. Coming up: The Design Spec

The Design Spec But really, how do I create a design spec? Find examples and use what you think is helpful from them! http: //www. mhhe. com/engcs/compsci/pressman/graphics/Pressman 5 sepa/common/cs 2/design. pdf http: //www. cmcrossroads. com/bradapp/docs/sdd. html Coming up: The Design Spec

The goal of design is to think with your brain, not your hands! - Dan Fleck Coming up: Applied Design

Applied Design We know what to do now, but that is just a set of documents. . How do we create a GOOD design? Coming up: Good Design

Good Design • Design Principles – What should you try to do. • Design Patterns – How have people done it before you? • Design Metrics – How do you know you have done it well? Coming up: Single Responsibility Principle

Single Responsibility Principle • Each class should have a single overriding responsibility (high cohesion) • Each class has only one reason for why it should change Coming up: Single Responsability Example

Single Responsability Example Student name address grades file. To. Save calculate GPA store. Student Coming up: Example: Paperboy and the Wallet student name student address grades which file we store the information in Why might this class definition change?

Customer Example: Paperboy and the Wallet get. First. Name() get. Last. Name() get. Wallet() Wallet add. Money(int a) subtract. Money(int a) count. Money() Paper. Boy’s get. Payment method: payment = 2. 00; // “I want my two dollars!” Wallet the. Wallet = my. Customer. get. Wallet(); if (the. Wallet. get. Total. Money() > payment) { the. Wallet. subtract. Money(payment); } else { // come back later and get my money } What is wrong with this? Coming up: Principle of Least Knowledge (aka Law of Demeter)

Principle of Least Knowledge (aka Law of Demeter) But not take them apart • “Only talk to your immediate friends” • Object O has a method M. – M may call other methods in O – M may call methods of any object passed into the method – M may call methods of any object it creates – M can call methods on any object contained in O Purpose: Reduce Coupling Coming up: Principle of Least Knowledge (aka Law of Demeter)

Customer Example: Paperboy and the Wallet get. First. Name() get. Last. Name() get. Wallet() Wallet add. Money(int a) subtract. Money(int a) count. Money() Bad because the paperboy needs to know about the Wallet (violation of principle of least knowledge), and also the customer has to hand the wallet to the paperboy (unrealistic) What is wrong with this? Coming up: Example: Paperboy and the Wallet

Customer Example: Paperboy and the Wallet get. First. Name() get. Last. Name() get. Payment(int amt) Wallet add. Money(int a) subtract. Money(int a) count. Money() Paper. Boy’s get. Payment method: payment = 2. 00; // “I want my two dollars!” int amt= my. Customer. get. Payment(payment); if (amt >= payment) { // say thanks! } else { // come back later and get my money } Better – paperboy only accesses what he needs and models the real world! This example from: http: //www. ccs. neu. edu/research/demeter-method/Law. Of. Demeter/paperboy/demeter. pdf Coming up: Interface Segregation Principle

Make

Interface Segregation Principle • Don’t make large multipurpose interfaces – instead use several small focused ones. • Don’t make clients depend on interfaces they don’t use. • Class should depend on each other through the smallest possible interface. • Why? When I change something I want to minimize changes for everyone else. Coming up: Interface Segregation Principle

Interface Segregation Principle public interface Worker { public void eat(); public void work(); } How to add a robot? public class Robot. Worker implements Worker { public class Office. Worker implements Worker{ public void work() {//. . working} public void eat() {//. . eating in lunch break} } public void work() { // Do work } public void eat() { throw new Not. Implemented. Exception(); } } Coming up: Interface Segregation Principle – Fixed!

Interface Segregation Principle – Fixed! public interface Worker { public void work(); } public interface Eater{ public void eat(); } public class Office. Worker implements Worker, Eater{ … } public class Robot. Worker implements Worker{ …} Now each interface has one purpose Coming up: Remove Cyclic Dependencies

Remove Cyclic Dependencies • Do not have cyclic dependencies in your packages • Decomposition into independent modules GUI • Why? Logic Business. Logic User. Logic Error. Handling Coming up: Design Patterns

Design Patterns • Proven solutions to common problems • Capture design expertise • Aid in meeting quality metrics • Core patterns are from the “Gang of Four (Go. F)” OOPSLA - 1994 Coming up: Singleton Pattern

Singleton Pattern • Problem: I want to limit the application to only one instance of a particular class, but need global access to that class. • Normally used to control access to key resources. • Solution? override new, make static accessor method. Coming up: Singleton Pattern (in Java)

Singleton Pattern (in Java) public class My. Singleton { private static My. Singleton instance; private My. Singleton() { // do anything you need to do } public static My. Singleton get. Instance() { if (instance == null) instance = new My. Singleton(); return instance; } } Coming up: Factory (Go. F 95)

Factory (Go. F 95) • Define an interface for a group of objects • Create a Factory to decide which specific object needs to be instantiated • The goal: decouple knowledge of the object instantiation from the Class that needs the object. • Can also be used when a complex initialization of objects is necessary, for instance when aggregation is heavily used. • Can also be used to take advantage of memory-optimization like object pools, cached objects, etc. Client Coming up: Factory (Go. F 95) Uses Factory Creates Product

Socket Factory (Go. F 95) Encrypted. Socket Product Encryption encrypt. Out decrypt. In Encrypts/Decrypts with instance: IEncrypt. Factory cipher: Encryption Client DESEncryption RSAEncryption Creates Encryption. Factory Create. Encryption(Key): Encryption Factory <<interface>> IEncrypt. Factory Create. Encryption(Key): Encryption Coming up: Factory (Go. F 95) Requests Creation

Socket Factory (Go. F 95) Encrypted. Socket Product Encryption encrypt. Out decrypt. In Encrypts/Decrypts with instance: IEncrypt. Factory cipher: Encryption Client DESEncryption RSAEncryption Creates Encryption. Factory Create. Encryption(Key): Encryption Factory How do we add another encryption method? Coming up: Command (Go. F 95) <<interface>> IEncrypt. Factory Create. Encryption(Key): Encryption Requests Creation

Command (Go. F 95) • Encapsulate commands in objects, so we can queue them, undo them or make macros. Abstract Command + manager: Cmd. Mgr * Concrete Command - data +do. It(): bool +undo. It(): bool Coming up: Design Patterns Summary +do. It(): bool +undo. It(): bool Macro. Command +do. It(): bool +undo. It(): bool

Design Patterns Summary • Many design patterns exist • Implementations are usually available in every language • Use them as guides where appropriate and make sure you understand the tradeoffs for each one. They usually need to be modified for YOUR situation. Coming up: What makes a design “bad”

What makes a design “bad” • Rigidity: It is hard to change because every change affects too many other parts of the system. • Fragility: When you make a change, unexpected parts of the system break. • Immobility: It is hard to reuse in another application because it cannot be disentangled from the current application. Coming up: Design Metrics From: http: //www. objectmentor. com/resources/articles/dip. pdf

Design Metrics • Class Size • Methods per class • Lack of Cohesion (count of methods with dissimilar purpose) • Coupling Between Classes (count of other classes that this class refers to) • Depth of Inheritance Tree • Method Complexity - tools can do this Coming up: Question

Question • How does cohesion apply to the interface segregation principle? Coming up: Design Summary

Design Summary • The design phase is when you plan HOW you implement your analysis • Use – Design Principles – Design Patterns – Design Metrics Coming up: References

References • Luc Berthouze, University of Sussex, http: //www. informatics. sussex. ac. uk/users/lb 203/se/SE 08. pdf • Robert Martin, Principles and Patterns, http: //www. objectmentor. com/resources/articles/Principles_and_Patterns. pdf • Bob Waters, Georgia Tech, CS 2340 Slides, http: //www. cc. gatech. edu/classes/AY 2007/cs 2340_summer/ • http: //www. surfscranton. com/architecture/Visitor. Pattern. htm • http: //www. oodesign. com/interface-segregation-principle. html Coming up: Dependency Inversion Principle

Principle of Least Knowledge (aka Law of Demeter) Simplified: • I can play by myself • I can play with toys given to me • I can play toys I made myself • I can play with my own toys (but not take them apart) Purpose: Reduce Coupling Coming up: Example: Paperboy and the Wallet