1. Dan Fleck CS 421 George Mason University
Design
Dan Fleck
CS 421
George Mason University
Coming up: What is the design phase?

2. 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

3. Analysis --> Design
Coming up: Analysis --> Design

4. Analysis --> Design
Coming up: Analysis --> Design

5. Analysis --> Design
Coming up: Analysis --> Design

6. Analysis --> Design
Coming up: Oversimplification

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

8. The Design Spec Architecture Design - Component design - UI design
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
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

9. The Design Spec But really, how do I do it?
Find examples and use what you think is helpful from them!
Coming up: The Design Spec

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

11. 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

12. Good Design Design Principles Design Patterns Design Metrics
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

13. 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: Example: Paperboy and the Wallet

14. Example: Paperboy and the Wallet
Customer
getFirstName()
getLastName()
getWallet()
PaperBoy’s getPayment method:
payment = 2.00; // “I want my two dollars!”
Wallet theWallet = myCustomer.getWallet();
if (theWallet.getTotalMoney() > payment) { theWallet.subtractMoney(payment);
} else { // come back later and get my money }
Wallet
addMoney(int a)
subtractMoney(int a)
countMoney()
What is wrong with this?
Coming up: Principle of Least Knowledge (aka Law of Demeter)

15. Principle of Least Knowledge (aka Law of Demeter)
“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 parameter passed into the M 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)

16. 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

17. Example: Paperboy and the Wallet
Customer
getFirstName()
getLastName()
getWallet()
Bad because the paperboy needs to know about the Wallet, and also the customer has to hand the wallet to the paperboy
Wallet
doesn’t model the real world and lets paperboy have WAY to much access!
addMoney(int a)
subtractMoney(int a)
countMoney()
What is wrong with this?
Coming up: Example: Paperboy and the Wallet

18. Example: Paperboy and the Wallet
Customer
getFirstName()
getLastName()
getPayment(int amt)
PaperBoy’s getPayment method:
payment = 2.00; // “I want my two dollars!”
int amt= myCustomer.getPayment(payment);
if (amt >= payment) { // say thanks!
} else { // come back later and get my money }
Wallet
addMoney(int a)
subtractMoney(int a)
countMoney()
Better – paperboy only accesses what he needs and models the real world!
This example from:
Coming up: Dependency Inversion Principle

19. Dependency Inversion Principle
Depend on abstractions, not concretions
Program to interfaces not implementations
Program to most abstract class possible
Why? Concrete classes may change a lot. Abstract classes/Interfaces generally change very little.
How can we ensure interfaces change very little? See next slide!
Answer: Add interfaces instead of modifying them.
Coming up: Interface Segregation Principle

20. 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: Remove Cyclic Dependencies

21. Remove Cyclic Dependencies
Do not have cyclic dependencies in your packages
Decomposition into independent modules
Why?
GUI
- Makes testing a much bigger problem
Logic
BusinessLogic
UserLogic
ErrorHandling
Coming up: Design Patterns

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

23. 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)

24. Singleton Pattern (in Java)
public class MySingleton {
private static MySingleton instance;
private MySingleton() {
// do anything you need to do }
public static MySingleton getInstance() {
if (instance == null) instance = new MySingleton();
return instance;
Coming up: Factory (GoF95)

25. Factory (GoF95) Define an interface for a group of objects
Create a Factory to decide which specific object needs to be instantiated
Think of a multi-document application framework. An application object may know when an object needs to be created, but not which object. How do we create the correct object when needed?
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.
Coming up: Factory (GoF95)

26. Factory (GoF95) Socket EncryptedSocket Encryption
instance:IEncryptFactory cipher: Encryption
encryptOut
decryptIn
Encrypts/Decrypts with
EncryptionFactory
DESEncryption
RSAEncryption
Requests
Creation
Creates
CreateEncryption(Key): Encryption
<<interface>>
IEncryptFactory
CreateEncryption(Key): Encryption
Coming up: Command (GoF95)

27. Command (GoF95)
Encapsulate commands in objects, so we can queue them, undo them or make macros.
Abstract Command
+ manager:CmdMgr *
MacroCommand
Concrete Command
+doIt():bool
+undoIt():bool
- data
+doIt():bool
+undoIt():bool
+doIt():bool
+undoIt():bool
Coming up: Flyweight (GoF95)

28. Flyweight (GoF95)
I have a bunch of classes, but I need to minimize the number of objects I am using.
Instances of the objects contain the same information and can be used interchangeably
Avoid the expense of multiple instances.
Example: DocChar class used to hold characters in a line of text
Coming up: Visitor (GoF95)

29. Visitor (GoF95)
If you need to perform an operation in multiple objects in a complex structure you could create the logic in each class.
OR…the visitor pattern creates a single class that implements the logic and knows how to “visit” each object in your complex structure
Coming up: Visitor (GoF95)

30. Visitor (GoF95)
I need to apply different operations to a collection of objects.
I want to centralize these operations
I want to reduce coupling
For example in a word processor, grammar check, spell check, table of contents builder, outliner all need to traverse the document.
Coming up: Visitor Diagram

31. Visitor Diagram Object with Structure concrete concrete visitor
navigates
Individual
Elements
Visitor
Coming up: Design Patterns Summary

32. 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 aren’t always good for YOUR situation
Coming up: Design Metrics

33. 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: Design Summary

34. Design Summary
The design phase is when you plan HOW you implement your analysis
Use
Design Principles
Design Patterns
Design Metrics
Coming up: What should you know

35. What should you know Analysis = what the system should do
Design = how it should do it
Meaning of the parts of the design spec
Design Principles:
Single Responsibility Principle - write it
Law of Demeter. Describe it and state why it is good.
3 rules of Dependency Inversion Principle
Why you need to remove cyclic dependencies
Metrics
Definition of cohesion and coupling - not how to calculate it, but what it means!
Be able to describe patterns - singleton, factory, command
Coming up: References

36. References
Luc Berthouze, University of Sussex,
Robert Martin, Principles and Patterns,
Bob Waters, Georgia Tech, CS2340 Slides,
End of presentation