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 INTUITIVEFLEXIBLE

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 ball inheritance composition has a isa “Think like an objective”

Composition and Inheritance ball sphere ball inheritance composition has a isa

Design Principle A B A B inheritance composition has a isa Favor composition over inheritance BLACK box reuseWHITE 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 (s)); else if (typeid(s) == typeid(Circle)) DrawCircle(static_cast (s)); } Shape SquareCircle

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 C has a this should work too Liskov substitution principle (LSP)

shoe high heelsneaker I need shoes … not to mention feet

shoe high heelsneaker 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-conditions post-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-conditions post-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