Design%20Patterns

1
Design Patterns

• Weslei A. de T. Marinho

2
Talk Outline

• Pattern Definition
• GRASP Patterns
• GoF Patterns
• GoF Patterns Classification
• Creational Patterns
• Structural Patterns

3
What is a Pattern?

• "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
What is a Pattern?

• 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
Why use Patterns?

• 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
Why use Patterns?

• 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
Types of Patterns

• GRASP Patterns
• Architectural Patterns
• Design Patterns
• Idioms
• E.g. Usability Patterns
• Anti-Patterns

8
Basic Pattern Metamodel
Pattern
Problem
Solution
name

Consequence
9
GoF Pattern Metamodel
Intent
SampleCode
ExampleDomain


A.K.A

Issues

Pattern
relPatterns

name
classification
Motivation (ExampleScenario)
Implementation Issue
Consequence
Participant
Applicability (Problem)



Structure (SolutionGraphicalDescription)
ClassDiagram
BehavioralStructure (Collaboration)
StaticStructure
ObjectDiagram
10
GRASP Patterns

• GRASP stands for General Responsibility
  Assignment Software Pattern
• Will be presented the following GRASP Patterns
• Information Expert
• Creator
• Low Coupling
• High Cohesion

11
Creator
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)
Solution (this can be viewed as advice) B "contains" or compositely aggregates A.
Solution (this can be viewed as advice) B records A.
Solution (this can be viewed as advice) B closely uses A.
Solution (this can be viewed as advice) 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
Creator Who creates the Square?
13
Information Expert
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
Information Expert
How to distribute the responsibilities for obtain
the sales total?
15
Low Coupling
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
High Cohesion
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
High Cohesion

• 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
GoF Patterns Classification
    Purpose Purpose Purpose
    Creational Structural Behavioral
Scope Class Factory Method Adapter Interpreter
Scope Class Factory Method Adapter Template Method
Scope Object Abstract Factory Adapter Chain of Responsibility
Scope Object Builder Bridge Command
Scope Object Prototype Composite Iterator
Scope Object Singleton Decorator Mediator
Scope Object   Facade Memento
Scope Object   Proxy Flyweight
Scope Object     Observer
Scope Object     State
Scope Object     Strategy
Scope Object     Visitor
Table 1  Design pattern space
19
Abstract Factory

• Intent Provide an interface for creating
  families of related or dependent objects without
  specifying their concrete classes.
• Also Knows As Kit

20
Abstract Factory - Motivation
21
Abstract Factory - Structure
22
Builder

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

23
Builder
24
Builder
25
Builder
26
Builder
27
Sigleton

• Intent Ensure a class only has one instance, and
  provide a global point of access to it.

28
Singleton
29
Adapter
30
Adapter
31
Adapter
32
Adapter
33
Adapter
34
Facade

• 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
Facade
36
Facade
37
Facade
38
Facade
39
Facade
40

• Dont ask!!!

41
Bibliography

• Freeman, E., Sierra, K., Bates, B. 2004. Head
  First Design Patterns. OReilly 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.