More Design
More Design
Next Tuesday
• First draft of architectural design– use cases– class diagrams for major classes with
responsibilities– sequence diagrams for use cases– identify important algorithms and data
structures and their parameters– critique with respect to good design principles
Next Tuesday
• First draft of architectural design
• Code/prototype
• Management update
Design
• Practices
• Principles
• Patterns
What are the characteristics of good design?
What are good solutions to common design problems?
How do we go about design and what do we produce?
TODAY:More Software design
Goals
1. Make it easy to build
2. Make it easy to test
3. Make it easy to maintain
4. Make it easy to change
INTUITIVE FLEXIBLE
Summary
• Use real world objects
• Single responsibility principle
• Encapsulate change
• High cohesion/low coupling
• Open-closed principle
• Don’t repeat yourself (D.R.Y)
• Law of demeter (talk only to your friends)
Composition and Inheritance
A B A
B
inheritance
composition
has a
isa
Composition and Inheritance
ball sphere sphere
ball
inheritance
composition
has a
isa
“Think like an objective”
Composition and Inheritance
ball sphere sphere
ball
inheritance
composition
has a
isa
Design Principle
A B A
B
inheritance
composition
has a
isa
Favor composition over inheritance
BLACK box reuse WHITE box reuse
Design Principle
shape square shape
square
inheritance
composition
has a
isa
Favor composition over inheritance
Caveat: sometime inheritance is the right thing (i.e. gives us polymorphism)
Bad design
void DrawShape(const Shape& s){if (typeid(s) == typeid(Square))
DrawSquare(static_cast<Square&>(s));else if (typeid(s) == typeid(Circle))
DrawCircle(static_cast<Circle&>(s));}
Shape
Square Circle
Design Principle
B
C
isa
Liskov substitution principle (LSP)
void doSomething(B myThingOfTypeB)
void doSomething(C myThingOfTypeC)
this should work as well
Design Principle
A B B
C
has a
isa
A Chas a
this should work too
Liskov substitution principle (LSP)
shoe
high heel sneaker
I need shoes …
not to mention
feet
shoe
high heel sneaker
I need high heels
LSP violation
rectangle
square
isa
class Rectangle{public:void SetWidth(double w) {itsWidth=w;}void SetHeight(double h) {itsHeight=w;}double GetHeight() const {return itsHeight;}double GetWidth() const {return itsWidth;}private:double itsWidth;double itsHeight;};
some time later …
LSP violation
rectangle
square
isa
class Rectangle{public:void SetWidth(double w) {itsWidth=w;}void SetHeight(double h) {itsHeight=h;}double GetHeight() const {return itsHeight;}double GetWidth() const {return itsWidth;}private:double itsWidth;double itsHeight;};
void Square::SetWidth(double w){Rectangle::SetWidth(w);Rectangle::SetHeight(w);}void Square::SetHeight(double h){Rectangle::SetHeight(h);Rectangle::SetWidth(h);}PROBLEMS?
void g(Rectangle& r){r.SetWidth(5);r.SetHeight(4);assert(r.GetWidth() * r.GetHeight()) == 20);}
LSP violation
rectangle
square
isa
class Rectangle{public:void SetWidth(double w) {itsWidth=w;}void SetHeight(double h) {itsHeight=w;}double GetHeight() const {return itsHeight;}double GetWidth() const {return itsWidth;}private:double itsWidth;double itsHeight;};
A square is not a rectangle!!Its external behavior is different
Design by contract
A--------------------------------
virtual doSomething() pre-conditionspost-conditions
LSP: If B’s pre-conditions is different than A’s, it must be weaker. If B’s post-condition is different than A’s, it must be stronger.
isa
B--------------------------------
doSomething() pre-conditionspost-conditions
Design Principle
INTUITIVE
FLEXIBle
Source: [Raymond, "Art of Unix Programming", Addison-Wesley, 2003]
• Rule of Modularity: Write simple parts connected by clean interfaces
• Rule of Clarity: Clarity is better than cleverness.
• Rule of Composition: Design programs to be connected to other programs.
• Rule of Separation: Separate policy from mechanism; separate interfaces from engines
• Rule of Simplicity: Design for simplicity; add complexity only where you must
• Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do
• Rule of Transparency: Design for visibility to make inspection and debugging easier
• Rule of Robustness: Robustness is the child of transparency and simplicity
• Rule of Representation: Fold knowledge into data so program logic can be stupid and robust
• Rule of Least Surprise: In interface design, always do the least surprising thing
• Rule of Silence: When a program has nothing surprising to say, it should say nothing
• Rule of Repair: When you must fail, fail noisily and as soon as possible
• Rule of Economy: Programmer time is expensive; conserve it in preference to machine time
• Rule of Generation: Avoid hand-hacking; write programs to write programs when you can
• Rule of Optimization: Prototype before polishing. Get it working before you optimize it
• Rule of Diversity: Distrust all claims for “one true way”
• Rule of Extensibility: Design for the future, because it will be here sooner than you think
UNDER-PROMISE and
OVER-DELIVER
• Choose 5 design principles (from last time or today)
• Critique your current domain/design model