Introduction to Design Patterns

2. Introduction to Design Patterns

3. Agenda Course Goal Engineering goal • Complex systems • Raw materials General Design • Bad design • Design principles Design Patterns • What is a Design Pattern? • Design Pattern space (catalog) • Design Patterns details Practice • Design a File System

4. Introduction Course Goal

5. Goal

6. Introduction Engineering Goal

7. Introduction - Engineering Goal Build complex systems • A complex system is not complicated • Differentiated – has many distinctive parts • Integrated - the several parts work together smoothly • The market seems to favour systems that are complex; i.e., differentiated and integrated at the same time.

8. Introduction - Engineering Goal Complicated systems

9. Introduction - Engineering Goal Raw “materials”: materials we can use in order to build such systems • Data • Logic • Time The “glue” • Coupling (static, dynamic, domain) Examples of coupling • Logic-Data-Time :structured programming • (Logic-Data)N –Time: single threaded OOP • ((Logic-Data)N –Time)M: multi threading OOP

10. Introduction General Design

11. Introduction - General Design Characteristics of a bad design • Rigidity - every change affects too many other parts of the system • Fragility - a change causes unexpected parts of the system break • Immobility - hard to reuse in another application Design Principles: guidelines that helps us to avoid having a bad design • Single Responsibility Principle • Open Close Principle • Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle

12. General Design – Bad Design Example: The “Copy” Program Responsibilities • Read characters from a keyboard • Write them to a printer Implementation • Problem • “Copy” module is not reusable in any context that does not involve a keyboard and a printer • Goal • Reuse the “Copy” module in other situations as well (e.g. copy from keyboard and write to a disk file)

13. General Design – Bad Design (continued) Solution 1 • Modify the “Copy” module to give it the new functionality • This adds new interdependencies to the system • As more devices will be added, “Copy” will become rigid and fragile

14. General Design – Bad Design (continued) Solution 2 • “Copy” depends upon abstractions • Now we can reuse the “Copy” module, independently of the “Keyboard Reader” and the “Printer Writer”

15. Design Principles Single Responsibility Principle

16. Design Principles Open Close Principle

17. Design Principles - Open Close Principle Software entities like classes, modules and functions should be open for extensionbut closed for modifications Open for Extension • The behavior of the module can be extended • New behaviors can be added Close for Modification • The source code of such a module is untouched New features are added by adding new code, rather than by changing old, already working, code Conformance to this principle yields: • Reusability • Maintainability Abstractionis the Key

18. Design Principles - Open Close Principle Everything works for a while

19. Design Principles Dependency Inversion Principle

20. Design Principles - Dependency Inversion Principle High-level modulesshould not depend on low-level modules • Both should depend upon abstractions Abstractions should not depend on details • abstract classes should not depend upon concrete classes; concrete classes should depend upon abstract classes Layering example

21. Design Principles Interface Segregation Principle

22. Design Principles – Interface Segregation Principle Clientsshould not be forced to depend upon interfaces that they do not use Add only methods that should be in an interface • ..otherwise the classes implementing the interface will have to implement those methods as well Example: Worker interface • Has “lunch break” method • What if the worker is a robot?

23. Design Principles Liskov’s Substitution Principle

24. Design Principles – Liskov’s Substitution Principle Derived typesmust be completely substitutable for their base types • new derived classes should be able to replace the base classes without any change in the code Example: Square - Rectangle

25. Introduction Design PatternsGoF (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides)

26. Practical exercise Design a File System

27. Design Patterns – What is a Design Pattern Adesign pattern is not a template—at least not in the sense of a dressmaker’s template, or a woodworker’s pattern It is not a recipe. You can’t just add ingredients and stir mindlessly to achieve a finished product So what is it?

28. Design Patterns - What is a Design Pattern A design pattern shouldn’t provide you with a solution, but it should inspire a solution Using Design Patterns • Can speed up the development process by providing tested, proven development solutions • Improves code readability for coders and architects familiar with the patterns • Allows developers to communicate using well-known, well understood names for software interactions

29. Design Patterns - Catalog

30. Design Patterns – Catalog (continued) Creational Patterns • Abstract the instantiation process • Help make a system independent of how its objects are created, composed, and represented Structural Patterns • Describe how classes and objects are composed to form larger, more complex structures Behavioral Patterns • Describe ways to handle algorithms and ways of communication between objects

31. Design Patterns - Template GoF uses the following template to describe a Pattern: Intent short description of pattern and its purpose Also Known As name alias Motivation motivating scenario demonstrating pattern's use Applicability circumstances in which pattern applies Structure graphical representation of the pattern Participants participating classes and/or objects and their responsibilities

32. Design Patterns – Template (continued) • Collaborations • how participants cooperate to carry out their responsibilities • Consequences • the results of application, benefits, liabilities • Implementation • implementation pitfalls, hints, or techniques, plus any language-dependent • issues • Sample Code • Known Uses • Related Patterns

33. Design Patterns Notations

34. Notations

35. Design Patterns Pattern Presentation

36. Pattern Presentations Composite Iterator Strategy State Template Method Decorator Proxy Factory Method Visitor Abstract Factory Observer Command Adapter Facade Singleton Bridge

37. Composite(structural)

38. Composite Intent Compose objects into tree structures Treat individual objects and compositions of objects uniformly

39. Composite - Motivation Example: Graphics applications such as drawing editors build complex diagrams out of simple components

40. Composite - Applicability • Use the Composite pattern when: • You want to represent hierarchies of objects • There should be no distinction between individual and composed elements, • Objects in the structure can be treated uniformly

41. Composite - Participants Component(Graphic) declares the interface for objects in the composition Leaf(Rectangle, Line, Text, etc.) represents leaf objects in the composition. A leaf has no children defines behavior for primitive objects in the composition

42. Composite – Participants (continued) Composite (Picture) defines behavior for components having children stores child components implements child-related operations in the Component interface Client manipulates objects in the composition through the Component interface

43. Composite - Collaborations Clients use the Component class interface to interact with objects in the composite structure If the recipient is a Leaf, then the request is handled directly If the recipient is a Composite, then it usually forwards requests to its child components

44. Composite – Consequences Definesclass hierarchies consisting of primitive objects and composite objects Primitive objects can be composed into more complex objects … which in turn can be composed … and so on recursively Wherever client code expects a primitive object, it can also take a composite object Makesthe client simple Clients don't know whether they're dealing with a leaf or a composite component Makesit easier to add new kinds of components Clients don't have to be changed for new Component classes Can make your design overly general Sometimes you want a composite to have only certain types of components

45. Iterator(behavioral)

46. Iterator Intent Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation Also Known As Cursor

47. Iterator - Motivation Example List Goal Access List’s elements without exposing its internal structure Allow different traversal types Allow multiple traversals at the same time Solution Move the traversal into a separate, Iterator object

48. Iterator – Motivation (continued) Two class hierarchies, one for lists and another for iterators CreateIterator method "connects" the two hierarchies

49. Iterator - Applicability Use the Iteratorpattern to: access an aggregate object's contents without exposing its internal representation support multiple traversals of aggregate objects provide a uniform interface for traversing different aggregate structures

50. Iterator - Participants Iterator defines an interface for accessing and traversing elements ConcreteIterator implements the Iterator interface keeps track of the current position in the traversal of the aggregate