1. D ESIGN P ATTERNS Weslei A. de T. Marinho

2. T ALK O UTLINE Pattern Definition GRASP Patterns GoF Patterns GoF Patterns Classification Creational Patterns Structural Patterns

3. W HAT IS A P ATTERN ? "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“ (Christopher Alexander)

4. W HAT IS A P ATTERN ? “Pattern is a named and well-known problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and discussion of its trade-offs, implementations, variations, and so forth.” (Craig Larman)

5. W HY USE P ATTERNS ? A pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it. Patterns document existing, well-proven design experience. Patterns identify and specify abstractions that are above the level of single classes and instances, or of components. Patterns provide a common vocabulary and understanding for design principles Patterns are a means of documenting software architectures.

6. W HY USE P ATTERNS ? Patterns support the construction of software with defined properties. Patterns help you build complex and heterogeneous software architectures. Patterns help you to manage software complexity.

7. T YPES OF P ATTERNS GRASP Patterns Architectural Patterns Design Patterns Idioms … E.g.: Usability Patterns Anti-Patterns

8. B ASIC P ATTERN M ETAMODEL Problem Solution Consequence Pattern name *

9. G O F P ATTERN M ETAMODEL Pattern name classification Intent Motivation (ExampleScenario) Applicability (Problem) * * Structure (SolutionGraphicalDescription) * BehavioralStructure (Collaboration) StaticStructure ClassDiagram ObjectDiagram Participant * Issues * Implementation Issue Consequence SampleCode * ExampleDomain * * relPatterns A.K.A

10. GRASP P ATTERNS GRASP stands for General Responsibility Assignment Software Pattern Will be presented the following GRASP Patterns: – Information Expert – Creator – Low Coupling – High Cohesion

11. C REATOR Name:Creator Problem:Who creates an A? Solution: (this can be viewed as advice) Assign class B the responsibility to create an instance of class A if one of these is true (the more the better): B "contains" or compositely aggregates A. B records A. B closely uses A. B has the initializing data for A. B is a creator of A objects. If more than one option applies, usually prefer a class B which aggregates or contains class A.

12. C REATOR – W HO CREATES THE S QUARE ?

13. I NFORMATION E XPERT Name:Information Expert Problem:What is a basic principle by which to assign responsibilities to objects? Solution: (advice)Assign a responsibility to the class that has the information needed to fulfill it. Problem: Who knows about a Square object, given a key?

14. I NFORMATION E XPERT How to distribute the responsibilities for obtain the sale’s total?

15. L OW C OUPLING Name:Low Coupling Problem:How to reduce the impact of change? Solution: (advice)Assign responsibilities so that (unnecessary) coupling remains low. Use this principle to evaluate alternatives. Given following classes: What is better for a makePayment design? A: B: In practice, the level of coupling alone can't be considered in isolation from other principles such as Expert and High Cohesion. Nevertheless, it is one factor to consider in improving a design.

16. H IGH C OHESION Name:High Cohesion Problem:How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling? Solution: (advice)Assign responsibilities so that cohesion remains high. Use this to evaluate alternatives.

17. H IGH C OHESION Low cohesion implies on code: Hard to comprehend Hard to reuse Hard to maintain Delicate; constantly affected by change In practice, the level of cohesion alone can't be considered in isolation from other responsibilities and other principles such as Expert and Low Coupling.

18. G O F P ATTERNS C LASSIFICATION Table 1: Design pattern space Purpose CreationalStructuralBehavioral Scope Class Factory MethodAdapterInterpreter Template Method Object Abstract FactoryAdapterChain of Responsibility BuilderBridgeCommand PrototypeCompositeIterator SingletonDecoratorMediator FacadeMemento ProxyFlyweight Observer State Strategy Visitor

19. A BSTRACT F ACTORY Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Also Knows As: Kit

20. A BSTRACT F ACTORY - M OTIVATION

21. A BSTRACT F ACTORY - S TRUCTURE

22. B UILDER Intent: Separate the construction of a complex object from its representation so that the same construction process can create different representations.

23. B UILDER

27. S IGLETON Intent: Ensure a class only has one instance, and provide a global point of access to it.

28. S INGLETON

29. A DAPTER

34. F ACADE Intent: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

35. F ACADE

40. Don’t ask!!!

41. B IBLIOGRAPHY Freeman, E., Sierra, K., Bates, B. 2004. Head First Design Patterns. O’Reilly Media, Inc. Gamma, E., Helm, R., Johnson, R., Vlissides, J. 1995. Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley Pub Co. Larman, C. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition. Pearson Education, Inc. Schmidt, D., Stal, M., Rohnert, H., Buschmann, F. 1996. PATTERN-ORIENTED SOFTWARE ARCHITECTURE VOLUME 1: A System of Patterns. John Wiley & Sons Ltd.