1. Week 2 Design Examples and Designing for Change Alex Baker

2. Implementation Design An implementation design is a road map – understandable, unambiguous, consistent, helpful, … An implementation design describes a path from system design to the outcome – correct, complete, concise, verifiable, effective, … An implementation design describes what the implementers should do – elegant, partitionable, recomposable, resilient, … An implementation design is a guide towards future change – evolvable, …

3. Emphasis: Changability Subtle Requires foresight and careful balancing An implementation design describes what the implementers should do – elegant, partitionable, recomposable, resilient, … An implementation design is a guide towards future change – evolvable, …

4. Emphasis: Changability Reusable Extensible Maintainable Portable Well-Documented Adaptable Simplicity Readability Minimalistic Elegant Well-Organized Concise Efficiency Powerful

5. Changability: Basic Principles Low Coupling: Reducing interdependency – Changes don’t propagate – Reuse is facilitated High Cohesion: Grouping functionality – Easier to find things – Metaphor guides decisions Information Hiding

6. Information Hiding Made Very Simple A List class with: 1) getArray() : Array 2) getElementAt(int i) : Element

7. Information Hiding Made Very Simple A List class with: 1) getArray() : Array 2) getElementAt(int i) : Element Its too slow, so we switch to a hash table 1) Everywhere you call getArray needs changing 2) Only List is changed Little things like this add up

8. The Ideal Program … vs.

9. Why the Emphasis on Changability? Change abounds… – During coding – After use – Reuse for later projects

10. Why is there so Much Change? Designs Outcomes

11. Why is there so Much Change? Designs Outcomes Engineering Physics Principles Existing Examples

12. Why is there so Much Change? Designs Outcomes Software Engineering Physics Principles Existing Examples

13. Why is there so Much Change? Designs Outcomes Software Engineering Physics Principles Existing Examples

14. Why is there so Much Change? Designs Outcomes Software Engineering Physics Principles Existing Examples

15. Why the Emphasis on Changability? Change abounds… – During coding – After use – Reuse for later projects You usually just don’t know for sure…

16. Changes During Coding Refinement of the high level design Dependencies reveal themselves – Oh, I need to know [X]. – I can’t access that data? ‘It turns out this class is HUGE’ Need to redesign as you go Can changes be made within the design?

17. Changes during Use Potential breakdowns at several levels – Customers have needs – Customers make requests – Developers provide software

18. Reuse A changing of context …

19. Change Happens Let’s design for it

20. Our Approach Lots of examples (3 problems, many solutions, today) Some overarching lessons Build up an intuition

21. UML Review: Class Diagrams Class Name Attribute : Type Operation (parameter) : Return Type Attribute : Type Operation (parameter) : Return Type

22. UML Review: Class Diagrams Association Aggregation Generalization Composition

23. A Class Diagram

24. Example #1: Theseus and the Minotaur http://www.logicmazes.com/theseus.html

25. Original Theseus Design

26. What if we want to add “Water” ?

27. Original Theseus Design What if we want to add “Water” ? ?

28. Original Theseus Design ? What if we want to add “Water” ? How do we fix this?

29. TntM: Changes Changing the board size Adding terrain types Adding more monsters Adding a second player “Intelligent elements”

30. TntM 2

31. TntM 2: Object Interfaces & Inheritance

32. TntM: Changes Changing the board size Adding terrain types Adding more monsters Adding a second player “Intelligent elements”

33. How far is too far? Changing board size? Pushable blocks? Intelligent elements? Real time gameplay? Physics challenges?

34. TntM 2

35. Bonus! StompOn( stompee ) Or StompedOn( stomper )

36. Aside: Three Degrees of Support Is it a good solution? Can they build that solution? Can that solution be used to make other good solutions?

37. Example #2 Klax Blocks fall from above, use a paddle to catch Deposit blocks in one of 5 columns Try to make lines of 3 in a row or more http://www.123games.dk/game/puzzle/klax3d/ klax_eng.php

38. A Good Klax Design?

39. Chiron 2 Architectural Style

40. C2 Klax

41. Spelling Klax?

43. Example #3: Scrabble

44. Function Overload Changes to rack

45. Class Overload

46. (besides missing details)

47. Is this a good design?

48. Overengineered? What change are you designing for? Multiple point values for a given tile type? More types of board objects?

49. Overengineered? Meanwhile: Board doesn’t actually work Populating the tiles is likely a hassle Tilepool vs. Player.currentTiles Inelegance lead to problems

50. A Nice Approach?

52. Scrabble Can a design accommodate: – Changes to letter values? – Changes to bonus squares? – AI opponents? – Different dictionaries?

53. Summary Designing for change is a matter of: – Controlling dependency – Proper encapsulation – Generalizing where you can Which changes? – What are the biggest change risks? – What kind of program is this, essentially? – Where is “the line”?

54. Practically: What is the core we know will be true? – What variations on that will we see? If there’s something that needs to change: – Can it be changed in one place? – Does anything else need to be changed when it changes? Can each class ignore its context? Discipline

55. Assignment #1 Continued []