Basic Design Patterns

1. Basic Design Patterns 1. Introduction Gabriel MañanaEd. 453 Of. 120 Ext. 14080gjmananag @unal.edu.co

2. Basic Design Patterns 1. Introduction What is a Design Pattern?Design Patterns in MVCDescribing Design PatternsCatalog of Design PatternsSolving Design ProblemsSelecting Design PatternsUsing Design Patterns

3. Basic Design Patterns • Designing OO software is hard • Designing reusable OO software is even harder

4. Basic Design Patterns • Find pertinent objects • Factor objects into classes • Define class interfaces • Define inheritance hierarchies • Establish key relationships

5. Basic Design Patterns The design should be specific to the problem at hand but also general enough to address future problems and requirements:  avoid redesign

6. Basic Design Patterns The difference between expert and novice designers is experience: Recurring patterns of classes and communicating objects.

7. Basic Design Patterns These patterns solve specific design problems and make OO designs more flexible:  reusable

8. Basic Design Patterns Each design pattern systematically names, explains and evaluates an important and recurring design in OO systems.

9. Basic Design Patterns Christopher Alexander: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

10. Basic Design Patterns • Essential pattern elements: • pattern name • problem • solution • consequences

11. Basic Design Patterns • 1. Pattern Name: • Let us design at a higher level of abstraction.

12. Basic Design Patterns • 2. Problem: • Explains the problem and its context. •  describes when to apply the pattern

13. Basic Design Patterns • 3. Solution: • Describes the elements that make up the design, their relationships, responsibilities and collaborations.

14. Basic Design Patterns • 4. Consequences: • Are the results and trade-offs of applying the pattern, its impact on a system’s flexibility, extensibility or portability

15. Basic Design Patterns Level of Abstraction? Description of communicating objects and classes that are customized to solve a general design problem in a particular context.

16. Basic Design Patterns The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities.

17. Basic Design Patterns It describes when it applies, whether it can be applied in view of other design constraints, and the consequences and trade-offs of its use. (code)

18. Smalltalk MVC Model/View/Controller Triad of classes used to build user interfaces  pattern

19. Smalltalk MVC Model: application objectView: its screen presentationController: describes the way the UI reacts to user input

20. Smalltalk MVC MVC: Decouples views and models by establishing a subscribe/notify protocol between them. (Observer Pattern)

21. Smalltalk MVC In MVC views can be nested: CompositeView, subclass of View. (Composite Pattern)

22. Smalltalk MVC MVC also allows to change the way a view responds to user input without changing its visual presentation. (Controller Pattern)

23. Smalltalk MVC View-Controller relationship is an example of the Strategy design pattern. (Strategy Pattern: an object that represents an algorithm)

24. Smalltalk MVC • MVC main relationships: • Observer • Composite • Strategy

25. Describing Design Patterns • Pattern Name • The pattern’s name conveys the essence of the pattern succintly.

26. Describing Design Patterns • Intent • What does the design pattern do? • What is the rationale and intent? • What particular design issue or problem does it address?

27. Describing Design Patterns • Also Known As • Other well-known names for the pattern, if any.

28. Describing Design Patterns • Motivation • A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem.

29. Describing Design Patterns • Applicability • What are the situations in which the design pattern can be applied? • What are examples of poor designs that the pattern can address?

30. Describing Design Patterns • Structure • A graphical representation of the classes in the pattern using a notation based on the Unified Modeling Language (UML). • Interaction diagrams are also used to illustrate sequences of request and collaborations between objects.

31. Describing Design Patterns • Participants • The classes and/or objects participating in the design pattern and their responsibilities.

32. Describing Design Patterns • Collaborations • How the participants collaborate to carry out their responsibilities.

33. Describing Design Patterns • Consequences • What are the trade-offs and results of using the pattern? • What aspect of system structure does it let vary independently?

34. Describing Design Patterns • Implementation • What pitfalls, hints or techniques should you be aware of when implementing the pattern? • Are there language-specific issues?

35. Describing Design Patterns • Sample Code • Code fragments that illustrate how you might implement the pattern.

36. Describing Design Patterns • Known Uses • Examples of the pattern found in real systems. • At least two examples from different domains.

37. Describing Design Patterns • Related Patterns • What design patterns are closely related to this one? • What are the important differences? • With other patterns should this one be used?

38. Catalog of Design Patterns Abstract Factory Provide an interface for creating families of related/dependent objects without specifying their concrete classes.

39. Catalog of Design Patterns Adapter Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of imcompatible interfaces.

40. Catalog of Design Patterns Bridge Decouple an abstraction from its implementation so that the two can vary independently.

41. Catalog of Design Patterns Builder Separate the construction of a complex object from its representation so that the same construction process can create different representations.

42. Catalog of Design Patterns Chain of Responsibility Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

43. Catalog of Design Patterns Command Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

44. Catalog of Design Patterns Composite Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

45. Catalog of Design Patterns Decorator Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

46. Catalog of Design Patterns Façade Provide a unified interface to a set of interfaces in a subsystem. Facades define a higher-level interface that makes the subsystem easier to use.

47. Catalog of Design Patterns Factory Method Define an interface for creating an object, but let subclasses decide which class instantiate. Factory Method lets a class defer instantiation to subclasses.

48. Catalog of Design Patterns Flyweight Use sharing to support large number of fine-grained objects efficiently.

49. Catalog of Design Patterns Interpreter Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

50. Catalog of Design Patterns Iterator Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.