Design Patterns

1. DesignPatterns

2. Everpresentproblems • Software engineers have to solve every day a lot of different problems of different nature. • The effectiveness of an engineer is measured by the time he/shee needs to diagnose, identify, and solve these problems. • The best engineer is who is able to apply the same solution (or similar) to solve similar problems.

3. Reinventingthewheel? • The idea that object-oriented design is based on of not reinventing the wheel is referred to the programmign process. So, why don’t we apply it during the analysis and design? • We need a way the share with other engineers the solutions we apply to these ever recurring problems. • So, we need to document these effective designs to make the communication easier.

4. Adaptationtothechange • Designing object-oriented software is hard, but designing reusable object-oriented software is even harder. • Design must be specific for the problem, but flexible enough to adapt it to future changes in the requirements avoiding as far as possible the redesign.

5. Fexibledesigns • Therefore... We need a flexible design. • And so... How do the good object-oriented designers do? • The have a great experience, because, • It takes a long time to learn to do good object-oriented designs. • Novice designers are prone to apply old non object-oriented techniques.

6. Typicalproblemshardtosolveon OO • How can I represent states using objects? • How can I guarantee that there will be one only instance of one specific class? • How can I add responsabilities dinamically –without using inheritance?

7. Why a Design Pattern? • Reusability:one of Wasserman’s rules(1996)for an efficient and actual SE discipline • Helping new designers to have a more flexible and reusable design • Improving the documentation and maintenance of existing system by furnishing an explicit specification of class and object interactions and their intent Design Patterns

8. History of Design Pattern • 1979:Christopher Alexander,architect, “The Timeless Way of Building”,Oxford Press • 1987:OOPSLA (Object Oriented Programming System),Orlando, presentation of design pattern to the community OO by Ward Cunningham and Kent Beck • 1995:Group of Four alias E.Gamma, R.Helm,R.Johnson and J.Vlissides : “Design Pattern:Elements of Reusable OO software” Design Patterns

9. Gang of Four • Pattern-based design was introduced into architecture and engineering in the 1950's • Almost immediately, software engineers began using patterns for designing software • It wasn't until a group of four researchers combined forces that pattern-based design became well-known and commonplace • This group was known as the gang of four (GoF)

10. Gang of Four • The gang of four (GoF) is: • Erich Gamma • Richard Helm • Ralph Johnson • John Vlissides • They are the authors of the famous text "Design Patterns: Elements of Reusable Object-Oriented Software"

11. But... What is a design pattern? • A pattern is an idea that has been useful in one practical context and will probably be useful in others • Martin Fowler • A pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution • Christopher Alexander

12. A patterns as a schema • A software design pattern provides a schema • It’s not an implemented artifact ready to be used (like utility classes or libraries) • It’s a mental built block to be implemented in many different applications and contexts. • There won’t be two identical implementations of the same pattern • The pattern does not define the relation between classes, but between the roles that classes play in the pattern. • Once the pattern is applied, the roles that each class plays in the pattern should be identified.

13. And... Why should we apply them? • Using patterns offers a few key advantages: • Leverage a proven solution • Provide a common vocabulary

14. Leverage a Proven Solution • The solution for a pattern has been designed, implemented and tested • Reusing these solutions allows most of each of these steps to be eliminated • If the implementation of a pattern is used, the design, implementation, and testing are minimal just to ensure the proper behaviour exists • If the design of a pattern is used, the solution specific to the problem must be implemented and tested, but need not be redesigned

15. Provide a Common Vocabulary • Some patterns are very common • Documenting and cataloguing patterns allows designers and architects to describe a solution using patterns as part of the language • Typically, this can make descriptions of solutions shorter • Architects and designers can more easily communicate their designs to their developers

16. Describing a pattern • More technical approach: A design pattern is a descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context • A pattern is made by four elements: • name • problem • solution • consequences Design Patterns

17. Name of Design Pattern • Describe a design problems and its solutions in a word or two • Used to talk about design pattern with our colleagues • Used in the documentation • Increase our design vocabulary • Have to be coherent and evocative Design Patterns

18. Problem • Describes when to apply the patterns • Explains the problem and its context • Sometimes include a list of conditions that must be met before it makes sense to apply the pattern • Have to occurs over and over again in our environment Design Patterns

19. Solution • Describes the elements that make up the design, their relationships, responsibilities and collaborations • Does not describe a concrete design or implementation • Has to be well proven in some projects Design Patterns

20. Consequences • Results and trade-offs of applying the pattern • Helpful for describe design decisions, for evaluating design alternatives • Benefits of applying a pattern • Impacts on a system’s flexibility,extensibility or portability Design Patterns

21. Description of Design Pattern • Pattern name and classification • contains the essence of pattern succinctly • Become part of your designvocabulary • Intent • What does the pattern do ? • What particular problem does it address ? Design Patterns

22. Description of Design Pattern • Motivation • Illustrate a design problem and how the class and the object structures solve the problem • Applicability • In which situations the pattern can be applied? • How can you recognize these situations? Design Patterns

23. Description of Design Pattern • Structure • Graphical representation of the classes and their collaborations in the pattern • Participants • Class • Objects • Responsibilities Design Patterns

24. Description of Design Pattern • Collaborations • How the participants collaborate to carry out their responsibilities • Consequences • How does the pattern support its objectives? • What are the trade-offs and results of using the pattern? Design Patterns

25. Description of Design Pattern • Implementation • Sample Code • Known Uses • Examples of the pattern found in real systems Design Patterns

26. Description of Design Pattern • Related Patterns • What design patterns are closely related to this one? • What are the important differences? Design Patterns

27. Types of patterns • There is first classification attending the abstraction level of the pattern: • Architectonic patterns • Design patterns • Code-focused patterns (idioms)

28. Architectonicpatterns • In a higher abstraction level, they define the architecture, the global structure of the system by means of subsystems and their relationships. • Example: Model-view-controller

29. Designpatterns • Midium abstraction level (design level) • More concrete that the architectural patterns, but still independent from the language. • Example: Observer

30. Idioms • Low-level patterns – coding • Most of them, language-specific. • They contribute to a uniform and consistent style of the programms in the specific language. • Example: • Coding stype guides • Smalltalk Best Practice Patterns (Kent Beck, 1997), • Effective C++ (Scott Meyers, 1997), • Java Style. Patterns for Implementation (Jeff Langr, 2000), etc.

31. Idioms • Example: Effective cause any Java-programmer undestand the pourpose of this code with a first quick look. Iterator iterator = list.iterator(); while (iterator.hasNext()) { Element object = (Element) iterator.next(); // ... }

32. Classification of Design Pattern By purpose and by scope • Creational patterns • Abstract the instantiation process • Make a system independent to its realization • Class Creational use inheritance to vary the instantiated classes • Object Creational delegate instantiation to an another object Design Patterns

33. Classification of Design Pattern • Structural patterns • Class Structural patterns concern the aggregation of classes to form largest structures • Object Structural pattern concern the aggregation of objects to form largest structures Design Patterns

34. Classification of Design Pattern • Behavioral patterns • Concern with algorithms and assignment of responsibilities between objects • Describe the patterns of communication between classes or objects • Behavioral class pattern use inheritance to distribute behavior between classes • Behavioral object pattern use object composition to distribute behavior between classes Design Patterns

35. Classification of design patterns ( a view) Design Patterns

36. And now, some case studies,… • Studying design patterns is not a trivial issue. • A design pattern can be understood in its own context, giving a solution for a problem • Let’s see a set of case studies that can be solved or simplified applying design patterns.

37. Example • Problem: I need a class “God” that can only have 1 instance. • Motivation:A God-object can do powerful things; one God-object is sufficient.For security I need to guarantee that there is indeed only one God-object, implying that it would be sufficient for me to monitor this single God. • Solution ??

38. Solution Singleton Pattern class God { … // fields and other methods here private God() { ... } ; static private God i = new God() ; public static God getInstance() { return i ; } } • God • i: God • God() • + God getInstance() pattern ! • Singleton • i: Singleton • Singleton() • + Singleton getInstance()

39. Problem: salary administrator • A salary administrator is responsible for calculating yearly bonus of employees.The algorithm to calculate this differs depending on an employee’s function. • Direct solution: List<Employee> elist Class SalaryAdminstrator { …calcBonus() { for (Employee e : elist) if (e.function == PROFESSOR) e.bonus = 0 else if (e.function == LECTURER) e.bonus = 1.9 * e.salary else e.bonus = 1.1 * e.salary } …

40. Solution : exploit subclassing Class SalaryAdminstrator { …calcBonus() { for (Employee e : elist) e.calcBonus() } … salary bonus Employee … + calcBonus() calcBonus() { bonus = 0 } calcBonus() { bonus = 1.9 * salary } Secretary … + calcBonus() Lecturer … + calcBonus() Professor … + calcBonus()

41. Strategy Pattern Client Strategy … + calc() 0..* 1 StrategyC … + calc() StrategyB … + calc() StrategyA … + calc()

42. What are the main guidelines ?? • Modularity ! • ExtensibilityWe should be able to extend a software without ‘changing’ the existing code. • ReusabilityWe should avoid replicating the same functionalities  error prone, and higher maintenance cost. • On the other hand, balance this with coupling/dependencyIncreasing the coupling also makes a software more error prone, and increases maintenance cost.

43. Problem : tables • A program wants to calculate the number of cells that a given table has.A table consists of rows. Each row consists of cells, and may be of different length. • Direct solution : Table class App { ...numCells(Table t) {inti = 0 ; for (Row r : t.rows) for (Cell c : r.cells) i++ ; return i ; } rows 0..* Row cells 0..* Cell

44. A nicer solution + numOfCells() : int 0..* Component children Cell Composite numOfCells() { return 1} numOfCells() { int k = 0 ; for (Component c : children) k = k + c.numOfCells() ; return k ; } Table Row Now "App" can just look like this : class App { ...numCells(Component c) { return c.numOfCells() ; } ...

45. "Composite" Pattern Component+ operation() 0..* Client children Composite + operation() + add(Component c) + remove(Component c) + getChildren() : List<Component> Cell + operation()

46. A D B C A B C D Problem: live charts This picture is taken from A.P. Mathur, slides "Design Patterns", CS 406 Software Engineering I, Purdue Univ. 2001. A=10 B=40 C=30 D=20 controller • We want to display this data in various charts. • There is a controller active that works on the data. • We want the change to be mirrored “live” in the charts.

47. Let’s look at similar but simpler problem Fahrenheit display Celcius display class Heater { int temp ; Thermometer ct ; Thermometer ft ; ... void change(int d) { temp = temp + d ; ct.update(temp) ; ft.update(9*temp/5 + 32) } } Heater Controller

48. Solution Make it so that we can add/remove thermometers. class Heater { private int temp ; public List<Thermometer> ts ; ... void change(int d) { temp = temp + d ;notify() ; } public void notify() { for (Thermometer t : ts) t.update(this) } } We can add/remove Thermometer to this list. Here is where we will put the temperature conversion.

49. Solution Thermometer - temp : int + update(Heater) Subject + add(Thermometer) + remove(Thermometer) + notify() oberservers 0..* FahThermometer CelciusThermometer Heater - temp : int update(h) { temp = h.temp } update(h) { temp = 9*h.temp/5 + 32 }

50. Observer Pattern Subject + add(Thermometer) + remove(Thermometer) + notify() Observer + update(Subject) oberservers 0..* ConcreteObs2 ConcreteObs1 ConcreteSubject