1. 1 Patterns in Object Oriented Programming A Concise Introductory Presentation Amnon H. Eden Tel Aviv University eden@math.tau.ac.il http://www.math.tau.ac.il/~eden Copyrights  All Rights Reserved No part of this document may be reproduced or distributed by any means without the prior written permission of the author. Permission is granted for individuals to read and use this document for self study.

2. 2 Contents Prologue: Motivation 1. Historical perspective 2. Terminology and taxonomy 3. Design patterns 4. Summary Epilogue: Future directions Appendix: References

3. 3 A Claim Today, design patterns make the most effective technique of conducting and training OOD !

4. 4 Prologue: Motivation “Software Engineering is an art rather than science” It requires: n Skill, talent, intelligence n Experience n Creativity, imagination, insight

5. 5 Motivation II There are about 3000 years of artistic experience to learn from... …but only some 20 years of experience with OOP! D:Delegator C1:Concrete_ State Client F 2: do1(a,b) 1: do1(a,b)

6. 6 Motivation III Patterns are about conveying skill and experience

7. 7 Part 1: Historical Perspective n The work of Christopher Alexander n Introducing patterns in OOP – The Hillside group and their work – A patterns hype

8. 8 Christopher Alexander An architect Relate publications: n The Timeless Way of Building (1979) n A Pattern Language (1977)

9. 9 The Work of Christopher Alexander Pattern: “A solution to a problem in a context”. Pattern language: A set of patterns used to solve closely related problems. Purpose: – effective reuse – dissemination of solutions

10. 10 Introducing Patterns into OOP n 1987: A workshop in OOPSLA by Beck & Cunningham n 1993: The Hillside Group - Beck, Cunningham, Coplien, Booch, Johnson,... n 1994: PLoP conference n 1995: Design Patterns: Elements of Reusable Object Oriented Software

11. 11 Part 2: Taxonomy Terms: n Pattern n Pattern language Related terms: n Design n Architecture n Framework n Library n Component

12. 12 Domain Specific Patterns n Communications and distributed processing n Operating systems and processes Business n Reactive systems n MMI-application interaction

13. 13 Language Specific Patterns Also called idioms C++: n Localized Ownership (PLoPD2) n Coplien: “Advanced C++ Programming styles and Idioms” Smalltalk: n Lazy Optimization (PLoPD2) n Beck: “Smalltalk Patterns: Best Practices”

14. 14 Dominant Pattern Domains Design patterns ! Architectural Patterns?

15. 15 Presenting a Pattern The common form: n Name n Intent n Solution n Consequences Other authors: n Name n Problem n [Context] n [Forces] n Solution

16. 16 Part 3: Design Patterns n The Gang of Four n Examples n Definitions n Observations and conventions n Summary

17. 17 The Gang of Four n Erich Gamma n Richard Helm n Ralph Johnson n John Vlissides Design Patterns: Elements of Reusable Object Oriented Software (1995).

18. 18 Design pattern: Iterator n Intent: Allow (iterative/sequential) access to elements of a data structure n Forces: Preserve data abstraction: Do not expose its internal structure

19. 19 Iterator Example i: List Iterator f1:File f2:File f3:File fileList: LinkedList :Link F current F next F element F next F element F F first...

20. 20 Iterator: Solution (general form) Aggregate createIterator( ) Insert( ) Remove( ) A Client Iterator First( ) Next( ) Prev( ) A Concrete Aggregate2 createIterator( ) Insert( ) Remove( ) Concrete Iterator2 First( ) Next( ) Prev( ) Concrete Aggregate1 createIterator( ) Insert( ) Remove( ) Concrete Iterator2 First( ) Next( ) Prev( )

21. 21 Design Pattern: Proxy n Problem: Defer the cost of object creation and init. until actually used n Applicability (possible contexts): – Virtual Proxy: Create an expensive object on demand (lazy construction) – Cache Proxy (PLoPD 2): Hold results temporarily – Remote Proxy: Use a local representative for a remote object (different address space) – Protection Proxy: Control access to shared object

22. 22 Sample Context: Word Processor Paragraph Document Paragraph Image document glyph Draw( ) DrawDetailed( ) Position( ) A paragraph Draw( ) DrawDetailed( ) Position( ) image Draw( ) DrawDetailed( ) Position( ) table Draw( ) DrawDetailed( ) Position( ) 0..n

23. 23 Forces 1. The image is expensive to load 2. The complete image is not always necessary 2MB 2KB optimize!

24. 24 Anti-Pattern Obviously, the document should not be aware to the optimization, nor to the image contents, etc. document::draw() { switch (glyph.type) { case image: if (cannot_optimize) load_full_image(); else optimize(glyph); break; case paragraph:...

25. 25 Proxy Solution (example) Image Proxy || file_name : String || get_image( ) Draft( ) DrawDetailed( ) Document Real Image || ImageData Glyph Draw( ) 0..n real_image Solution: Provide a “surrogate” or place-holder which provides transparent access to another object

26. 26 Proxy Solution (example): Object Diagram aDocument image Proxy theBitmap: RealImage 1: DrawDetailed ( ) 3: new (fileName) 2: get_image ( ) 4: DrawDetailed( )

27. 27 Proxy Solution (general form) RealSubject Request( ) Proxy Request( ) Subject Request( ) client realSubject

28. 28 Definitions of Design Patterns n GoF: Description of communicating objects and classes that are customized to solve a general design in a particular context n Coplien & Schmidt: Design patterns capture the static and dynamic structures of solutions that occur repeatedly when producing applications in a particular context

29. 29 Design Pattern: Observer n Problem: Decouple a data model from “parties” interested in its internal state n Forces – The identity and number of receivers is not predetermined – Receivers of novel classes may be added to the system in the future – Polling is inappropriate (too expensive, etc.)

30. 30 Observer Example: File System Remote File Server Window in PC 1 Window in PC 2

31. 31 Observer: Solution Subject::Notify() { for (i = 0; i < _ObsNumber; i++) _my_obs[i]->Update(this); } ConcreteSubject::ChangeData() { // Chnage data somehow Notify(); } Observer 1 Update(subject *) Concrete Subject ChangeData( ) Observer Update(subject *) = 0 A Subject Attach(Observer*) Detach(Observer *) Notify() my_obs 1 0..n Observer 2 Update(subject *)

32. 32 The Observer Ignores: n How information about the change is conveyed n Refining the mechanism for different kinds of changes... Different implementations conform to the same pattern ! (Variations listed in: “Implementation Patterns for the Observer Pattern”, Kim & Benner, PLoPD2)

33. 33 Design pattern: Strategy n Intent: Let each member of a family of algorithms vary independently from clients that use it n Forces: – input depends on the algorithm – calculations are based on the client’s abstraction (not using client’s implementation or global data)

34. 34 Strategy sample: I Traffic Lights Control Strategy sample: Intersection Traffic Lights Control The light- switching policy changes by the hour

35. 35 The Behavior Varies n The “dumb” policy: change the green route every 5 seconds n Midnight policy: change to green whenever a “sensor” detects a vehicle n Rush hour policy: double the “green time” in the busy route n …

36. 36 Anti-Pattern Use multiple conditional statement to set the behavior according to current policy intersection::next_green(the_green_route r) { switch (current_policy) { case dumb: next_time := time + constant_time; case midnight: if (not the_green_route.is_busy) then … case rush_hour: … }

37. 37 Strategy Solution (example) Intersection TheConstantTime( ) PreviousGreenRoute( ) ThisGreenRoute( ) TraficRouting Policy compute_change_time() DumbPolicy compute_change_time() Midnight Policy compute_change_time() RushHour Policy compute_change_time() Emergency Policy compute_change_time() current_policy

38. 38 Strategy Solution (example) Interaction Diagram theIntersection current_policy: rush_hour 1: compute_change_time(self) 2: const_time ( ) 4: change_time_is (2 * 13) 3: const_time_is (13)

39. 39 Strategy: Consequences n Easy to add new strategy (or remove an existing one, etc.) For instance: From 8 a.m. to 10 a.m. there is no turn left from Dizengof to Arlozorov

40. 40 Strategy: Consequences II n Easy to factor out similar strategies (using inheritance) RushHour Policy compute_change_time() Morning RushHour busy_direction( ) Afternoon RushHour busy_direction( ) rushHour::compute_change_time(intersection inter) { if (inter.curr_green_route == busy_direction()) return (inter.const_time * 2) else return (inter.const_time); }

41. 41 Part 4: Design Patterns - Summary n Perspectives n Observations n Types of design patterns n The Merits of Patterns

42. 42 Perspectives on Patterns I “Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.” [GoF 95, p. 24]. For instance: – Observer: the observers vary independently – Strategy: the strategies vary independently – Iterator: the data structures vary independently

43. 43 Perspectives II Design patterns are recurring building blocks of rough granularity X Y Z Observer 1 Update(subject *) Concrete Subject ChangeData( ) Observer Update(subject *) = 0 A Subject Attach() Detach(Observer *) Notify() my_obs 1 0..n Observer 2 Update(subject *)

44. 44 Perspectives III: Patterns Combine & Interact Real Image Observer Update(subject *) = 0 A Subject Attach() Detach() Notify() 1 n Image Proxy Update(Subject *) Glyph Document || file_name : String get_image( ) 0..n

45. 45 Perspectives IV Patterns are of different levels of abstraction Pattern A Pattern B Pattern C

46. 46 Observation: The specified solution is not always complete in detail. Possible reasons: – Context dependent – Language dependent – There are many possible implementations with similar results (difference does not count) – It cannot be precisely formulated (but only expressed in natural language)

47. 47 Summary: The Merits of Patterns

48. 48 Merits of Patterns I: Merits of Patterns I: Higher Level of Abstraction

49. 49 Merits of Patterns II: Merits of Patterns II: Improved Design “reuse” ideas (as opposed to pieces of code) better understanding of mechanisms: do not repeat mistakes or “reinvent the wheel” RealSubject Request( ) Proxy Request( ) Subject Request( ) client realSubject

50. 50 Merits of Patterns III: Merits of Patterns III: Improve all Forms of Communication documenting group planning and design presenting or learning an existing system Patter n

51. 51 Merits of Patterns IV: Training dissemination of solutions recording the expert’s experience

52. 52 Classifications of Design Patterns Each design pattern dictates structure and/or interaction protocol Patterns are classified according to structure and/or protocol n Structural: how classes and objects form structures n Behavioral: patterns of communications, assigning responsibilities n Creational: abstract the instantiation process

53. 53 Conventions and Beliefs About Patterns n It must be documented in at least 3 distinct applications before it is a “pattern” n A paper should go through a writer’s workshop before it is published n It cannot be “coded” in a conventional OOPL

54. 54 Epilogue: Future Directions Open problems: n Classification and indexing n Tool support n Formalization n Analysis patterns Questions: n Will patterns survive? n Will the industry of patterns converge?

55. 55 Appendix: References n Books n Articles

56. 56 Collections of Patterns n Gamma, Helm, Johnson, Vlissides (1995). Design Patterns: Elements of Reusable O-O Software n Coplien & Schmidt, eds. (1994). Pattern Languages of Program Design (AKA PLoPD 1). n Vlissides, Coplien & Kerth, eds. (1995). Pattern Languages of Program Design 2 (AKA PLoPD 2). n Buschmann et. al (1996). Pattern-Oriented Software Architecture (AKA The Siemens Book). n Martin R., D. Riehle, F. Buschmann, eds. (1997) Pattern Languages of Program Design 3. n Fowler (1997). Analysis Patterns.

57. 57 PLoP Conferences PLoP = Pattern Languages of Programming Twice a year, since 1994: n PLoP USA n EuroPLoP Purpose: Promote good pattern papers Products: PLoPD books Pattern

58. 58 Web Sites n Patterns home page: http://hillside.net/patterns/patterns.html

59. 59 Articles n Beck & Johnson 1994. Patterns Generate Architecture. ECOOP 94 n Schmidt D. Overview of Patterns and Pattern Languages. CACM, Vol. 39, No. 10, October 96. n Vlissides J. To Kill a Singleton. C++ Report, June 1996.

60. 60 Discussion Groups n Discussion groups: – Tel Aviv – New York – Washington – Florida – Stockholm