1. More Design

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

3. Next Tuesday First draft of architectural design Code/prototype Management update

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

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

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

7. Composition and Inheritance A B A B inheritance composition has a isa

8. Composition and Inheritance ball sphere ball inheritance composition has a isa “Think like an objective”

9. Composition and Inheritance ball sphere ball inheritance composition has a isa

10. Design Principle A B A B inheritance composition has a isa Favor composition over inheritance BLACK box reuseWHITE box reuse

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

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

13. Design Principle B C isa Liskov substitution principle (LSP) void doSomething(B myThingOfTypeB) void doSomething(C myThingOfTypeC) this should work as well

14. Design Principle A B B C has a isa A C has a this should work too Liskov substitution principle (LSP)

15. shoe high heelsneaker I need shoes … not to mention feet

16. shoe high heelsneaker I need high heels

17. 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 …

18. 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?

19. void g(Rectangle& r) { r.SetWidth(5); r.SetHeight(4); assert(r.GetWidth() * r.GetHeight()) == 20); }

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

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

22. Design Principle INTUITIVE FLEXIBle

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

24. UNDER-PROMISE and OVER-DELIVER

25. Choose 5 design principles (from last time or today) Critique your current domain/design model