1. Design II Today: Design Principles…can we define them intro.12.ppt CS 121 “Ordering Chaos” “Mike” Michael A. Erlinger

2. – 2 – CS 121 Design PracticesPrinciplesPatterns 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? LAST TIME

3. – 3 – CS 121 Practices: Forms of Models Diagrams (UML) Text (hyperlinked) Prototypes Mathematical models Charts, graphs LAST TIME

4. – 4 – CS 121 Design PracticesPrinciplesPatterns 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: Principles of design Are there any? Do they matter? Can we evaluate them?

5. – 5 – CS 121 Goals at the Highest Level 1.Make it easy to build 2.Make it easy to test 3.Make it easy to maintain 4.Make it easy to change SIMPLE FLEXIBLE INTUITIVE

6. – 6 – CS 121 Mountains and molehills Design principles help manage the complexity that arises as project size grows. Software development in the: Small vs Large Problem is: Small grows to Large without a plan

7. – 7 – CS 121 Design Principle: DRY Don’t repeat yourself data/code should occur once and only once Examples: ?? SIMPLE, INTUITIVE, FLEXIBLE

8. – 8 – CS 121 Design Principle: Use real world objects INTUITIVE Domain model Design model Abstract: Game Real: Game console

9. – 9 – CS 121 Design Principle: SRP Single Responsibility Principle (SRP) every class/object should have a single responsibility SIMPLE, INTUITIVE, FLEXIBLE Several related principles Encapsulation, Abstraction, etc. Foundation of Software Development: Functions with single purpose, Objects, etc.

10. – 10 – CS 121 Design Principle: EV Encapsulate Variation every class should have only one reason to change FLEXIBLE Change should not cause a domino effect! related to SRP

11. – 11 – CS 121 EV example … Image processor bmp, Purpose: Convert images What happens when Input type changes?

12. – 12 – CS 121 EV example … Image processor bmp, Sometime Later: jpg, gif, … Image Loader bmp, Sometime Later: jpg, gif, …

13. – 13 – CS 121 Design Principle: HCLC High cohesion Low coupling related to SRP A class is cohesive if its data and methods are strongly connected Classes have low coupling if they are only loosely connected

14. – 14 – CS 121 Cohesion: Examples Functional cohesion (SRP): Coincidental cohesion: Logical cohesion: Temporal/sequential cohesion: Communicational: ?

15. – 15 – CS 121 Cohesion: Examples Functional cohesion (SRP): grouped because they contribute to a single well-defined task Coincidental cohesion: grouped together because Logical cohesion: grouped because they fall into some logical category, i.e. I/O Temporal/sequential cohesion: grouped because they are processed at the same time or in sequence; i.e. error handling (create log, notifies user, etc.) Communicational: grouped because they operate on same data, e.g., operate on same record BEST WORST

16. – 16 – CS 121 Coupling: Examples Content coupling: Common coupling: Control coupling: Data-structure coupling: Message coupling: ?

17. – 17 – CS 121 Coupling: Examples Content coupling: a module or class relies on the implementation of another; i.e. accessing private data Common coupling: modules or classes share global data Control coupling: one module controls the logic of another (e.g. passing a what-to-do flag) Data-structure coupling: modules share composite data structure Message coupling: modules communicate through interface BEST WORST

18. – 18 – CS 121 Design principle Law of Demeter Principle of Least Knowledge no no no: myGame->theBoard->cells[0][0].update() only talk to your friends

19. – 19 – CS 121 Design principle Law of Demeter no no no: myGame->theBoard->cells[0][0].update() Should not know details of theBoard only talk to your friends Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Each unit should only talk to its friends; don't talk to strangers. Only talk to your immediate friends. The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents).

20. – 20 – CS 121 Design Principle: Open-Closed principle classes should be open to extension but closed to modification architecture of your game

21. – 21 – CS 121 Design Principle: Open-Closed principle classes should be open to extension but closed to modification idea was that once completed, the implementation of a class could only be modified to correct errors; new or changed features would require that a different class be created architecture of your game

22. – 22 – CS 121 Composition and Inheritance ball sphere ball has a is a Design heuristic: Think like an object! shape is a

23. – 23 – CS 121 Design Principle A B A B inheritance composition has a isa Favor composition over inheritance BLACK box reuseWHITE box reuse

24. – 24 – CS 121 Design principle A B A B inheritance composition has a isa Favor composition over inheritance Caveat: sometime inheritance is the right thing (i.e. gives us polymorphism)

25. – 25 – CS 121 Design Principle: LSP B C isa Liskov substitution principle (LSP) void doSomething(B myThingOfTypeB) void doSomething(C myThingOfTypeC) this should work as well not just any banana

26. – 26 – CS 121 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 …

27. – 27 – CS 121 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?

28. – 28 – CS 121 LSP: Assume a Square class that derives from a Rectangle class, assuming getter and setter methods exist for both width and height. The Square class always assumes that the width is equal with the height. If a Square object is used in a context where a Rectangle is expected, unexpected behavior may occur because the dimensions of a Square cannot (or rather should not) be modified independently. Assume a Square class that derives from a Rectangle class, assuming getter and setter methods exist for both width and height. The Square class always assumes that the width is equal with the height. If a Square object is used in a context where a Rectangle is expected, unexpected behavior may occur because the dimensions of a Square cannot (or rather should not) be modified independently. This problem cannot be easily fixed: if we can modify the setter methods in the Square class so that they preserve the Square invariant (i.e., keep the dimensions equal), then these methods will weaken (violate) the postconditions for the Rectangle setters, which state that dimensions can be modified independently. This problem cannot be easily fixed: if we can modify the setter methods in the Square class so that they preserve the Square invariant (i.e., keep the dimensions equal), then these methods will weaken (violate) the postconditions for the Rectangle setters, which state that dimensions can be modified independently.

29. – 29 – CS 121 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

30. – 30 – CS 121 Design Principle INTUITIVE SIMPLE FLEXIBLE

31. – 31 – CS 121 Summary Don’t repeat yourself (D.R.Y) Use real world objects Single responsibility principle Encapsulate variation High cohesion/low coupling Program to an interface, not an implementation Law of Demeter (talk only to your friends) Favor composition over inheritance Open-closed principle Liskov Substitution Principle

32. – 32 – CS 121 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

33. – 33 – CS 121 Agile Design Philosophies Agile Designs are Emergent…Agile Designs are Emergent… Unit tests form detailed design doc WHEN do test-driven development (TDD)Unit tests form detailed design doc WHEN do test-driven development (TDD) Design models need to be just barely good enoughDesign models need to be just barely good enough Multiple models usedMultiple models used Use each model in multiple waysUse each model in multiple ways Designers should codeDesigners should code Prove it with codeProve it with code Feedback is your friend (team and/or outsiders)Feedback is your friend (team and/or outsiders) Iterate, iterate, iterateIterate, iterate, iterate Do design every dayDo design every day Document complicated thingsDocument complicated things Do not over document…until the endDo not over document…until the end

34. – 34 – CS 121 Agile Design Philosophies… Incorporate continuous User feedbackIncorporate continuous User feedback Understand your stakeholders…users, management, …Understand your stakeholders…users, management, … Design for the user experienceDesign for the user experience Make the app predictableMake the app predictable Bring objects to life through UIBring objects to life through UI

35. – 35 – CS 121 UNDER-PROMISE and OVER-DELIVER

36. – 36 – CS 121 The End

37. – 37 – CS 121 Trade offs Class A Class B Class C low cohesion high coupling