more design. next tuesday first draft of architectural design –use cases –class diagrams for...

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