1. ANU COMP2110 Software Design in 2004 Lecture 15Slide 1 COMP2110 in 2004 Software Design Lecture 15: Software design patterns (2) 1What are design patterns? 2Where do they come from? 3Why study them? 4What are they again? 5More thoughts: Abstraction Don’t reinvent the wheel Consequences

2. ANU COMP2110 Software Design in 2004 Lecture 15Slide 2 What are design patterns? First, some examples of what they are not: adjustable templates like dress patterns as in “pattern matching”, like regexps repeated motifs like in art or music, e.g. Islamic decorative art harpsichord cadenza from the 5th Brandenburg concerto jazz riffs

3. ANU COMP2110 Software Design in 2004 Lecture 15Slide 3 So what are design patterns? Examples of reusable, excellent object-oriented software design, together with the context in which each one applies the problem it tries to solve the forces at work the consequences of adopting it hints for implementation

4. ANU COMP2110 Software Design in 2004 Lecture 15Slide 4 What is the origin of design patterns? Started in architecture with the work of Christopher Alexander and his group at Berkeley. He asked: What makes great buildings great and awful buildings awful? When great buildings can be so different, what do they have in common? He looked very hard for examples and principles, working at a very subtle level Looked at different ways to solve the same problem Came up with a whole system for design

5. ANU COMP2110 Software Design in 2004 Lecture 15Slide 5 What does this have to do with software? In the early 90’ssome software people read Alexander’s work and saw a parallel The same problems occur again and again and can be solved the same way These examples of partial designs can be reused at the level of ideas, not of code Gamma, Helm, Johnson & Vlissides wrote the “Gang of Four” book An explosion of interest and activity since then

6. ANU COMP2110 Software Design in 2004 Lecture 15Slide 6 Why study design patterns? To learn some examples of great design that you can use To create a common vocabulary for talking about design To help you think about design at a higher level of abstraction To learn from them, so that you can apply the same principles to create great designs of your own

7. ANU COMP2110 Software Design in 2004 Lecture 15Slide 7 What is a design pattern again? A solution to a problem in a context Example: The Observer pattern Context: Many objects, of varying number and different types, depend on another object and need to stay synchronised with it. Problem: How to manage that without having to change all the code every time a new type of observer comes along. Solution: See previous lecture, textbook, GoF book

8. ANU COMP2110 Software Design in 2004 Lecture 15Slide 8 Clock display using observer pattern main driver loop: loop t = system.clock_time() for all zc in clocks do zcv.update_timer(t) this.suspend(interval) end loop update_timer(time t) is zoned_time =t+zone_offset for all cd in displays do cd.redisplay() end update_timer analogue redisplay() is dt = master.get_time h_angle = 360*hours(dt)/12 etc. etc.

9. ANU COMP2110 Software Design in 2004 Lecture 15Slide 9 More thoughts: Abstraction Abstraction is about choosing what details to leave out Just keep the important ones To understand and apply design patterns well, you have to learn to do this How hard or easy this is for you depends on your personality type

10. ANU COMP2110 Software Design in 2004 Lecture 15Slide 10 More thoughts: Don’t reinvent the wheel Name: Wheel Intent: Transport heavy loads long distances Problem: They’re hard to carry, but it’s really important to move stuff like food around Solution: Build vehicles with wheels, and smooth roads for them to run on Consequences: Greatly increased capacity and speed. Need roads. Control of roads = power... Implementation: Another time... Alternatives: Carry it, drag it, use a boat or barge

11. ANU COMP2110 Software Design in 2004 Lecture 15Slide 11 More thoughts: Consequences Need to think in terms of cause and effect There is no absolute good and bad, only choices and their consequences In software we measure quality against requirements (and meta-requirements like extendability and reusability that often aren’t written down) When you make design decisions, look at the practical consequences Using a pattern isn’t always a good decision!

12. ANU COMP2110 Software Design in 2004 Lecture 15Slide 12 More thoughts: Principles Prefer composition over inheritance Find what varies and encapsulate it Improve modifiability