Design
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
The Design Spec
Architecture 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
The Design Spec
But really, how do I do it?
Find examples and use what you think is helpful
from them!
http://www.mhhe.com/engcs/compsci/pressman/graphics/Pressman5sepa/common/cs2/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: Example: Paperboy and the Wallet
Customer
Example: Paperboy and
the Wallet
getFirstName()
getLastName()
getWallet()
Wallet
addMoney(int a)
subtractMoney(int a)
countMoney()
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
}
What is wrong with this?
Coming up: Principle of Least Knowledge (aka Law of Demeter)
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)
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
Customer
Example: Paperboy and
the Wallet
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
addMoney(int a)
subtractMoney(int a)
countMoney()
What is wrong with this?
Coming up: Example: Paperboy and the Wallet
Customer
Example: Paperboy and
the Wallet
getFirstName()
getLastName()
getPayment(int amt)
Wallet
addMoney(int a)
subtractMoney(int a)
countMoney()
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
}
Better – paperboy only accesses what
he needs and models the real world!
This example from: http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paperboy/demeter.pdf
Coming up: Dependency Inversion Principle
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!
• Why? Using an interface allows code
flexability to changes without affecting other
parts.
Coming up: Interface Segregation Principle
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
Remove Cyclic Dependencies
• Do not have cyclic dependencies in
your packages
• Decomposition into independent
modules
GUI
• Why?
Logic
BusinessLogic
UserLogic
ErrorHandling
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 (GoF)”
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 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)
Factory (GoF95)
• 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 (GoF95)
Uses
Factory
Creates
Product
Socket
Factory (GoF95)
EncryptedSocket
Encryption
encryptOut
decryptIn
Encrypts/Decrypts with
DESEncryption RSAEncryption
Creates
How do we add
another encryption
method?
Coming up: Command (GoF95)
instance:IEncryptFactory
cipher: Encryption
EncryptionFactory
CreateEncryption(Key): Encryption
<<interface>>
IEncryptFactory
CreateEncryption(Key): Encryption
Requests
Creation
Command (GoF95)
• Encapsulate commands in objects, so we can
queue them, undo them or make macros.
Abstract Command
+ manager:CmdMgr
*
Concrete Command
+doIt():bool
+undoIt():bool
MacroCommand
- data
+doIt():bool
+undoIt():bool
Coming up: Flyweight (GoF95)
+doIt():bool
+undoIt():bool
Flyweight (GoF95)
• I have a bunch of classes, each takes up a lot of
memory, so I need to minimize the number of them
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. Picture is stored once, location is
stored for every instance.
Coming up: Visitor (GoF95)
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)
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.
– Solution: Create a Visitor to visit the whole
document and apply the operation given
Coming up: Visitor Traversal Example
Visitor Traversal Example
• root.accept(theVisitor);
• accept(Visitor visitor )
visitor.visit( this ); // Do operation
for each child of mine
child.accept( visitor ) // Visit children
• All children are visited, but the caller
doesn’t need to know “how”
• Supports multiple class types also…
Coming up: Visitor Traversal Example
Visitor Traversal Example
• visit(Document node);
• visit(Sentence node);
• visit(Word w);
• The correct version is called based on
the runtime type of the child! (Hello
Polymorphism!)
Coming up: Visitor Example – Different operation to collection
Visitor Diagram
Bold
concrete
visitor
Object with
Structure
Spell Check
concrete
visitor
Visitor
Coming up: Design Patterns Summary
navigates
Individual
Elements
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.
From: http://www.objectmentor.com/resources/articles/dip.pdf
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
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
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
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
References
•
Luc Berthouze, University of Sussex,
http://www.informatics.sussex.ac.uk/users/lb203/se/SE08.pdf
•
Robert Martin, Principles and Patterns,
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
•
Bob Waters, Georgia Tech, CS2340 Slides,
http://www.cc.gatech.edu/classes/AY2007/cs2340_summer/
•
http://www.surfscranton.com/architecture/VisitorPattern.htm
End of presentation