DESIGN PATTERNSWeslei A. de T. Marinho

TALK OUTLINE

Pattern Definition GRASP Patterns GoF Patterns

GoF Patterns Classification Creational Patterns Structural Patterns

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)

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)

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.

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.

TYPES OF PATTERNS

• GRASP Patterns• Architectural Patterns• Design Patterns• Idioms

• …• E.g.: Usability Patterns• Anti-Patterns

BASIC PATTERN METAMODEL

Problem Solution

Consequence

Pattern

name

*

GOF PATTERN METAMODEL

Pattern

name

classification

Intent

Motivation(ExampleScenario)

Applicability(Problem)

*

*

Structure(SolutionGraphicalDescription

)

*

BehavioralStructure(Collaboration)

StaticStructure

ClassDiagram

ObjectDiagram

Participant*

Issues*

ImplementationIssue

Consequence

SampleCode

*

ExampleDomain *

*

relPatterns

A.K.A

GRASP PATTERNS

• GRASP stands for General Responsibility Assignment Software Pattern

• Will be presented the following GRASP Patterns:– Information Expert– Creator– Low Coupling– High Cohesion

CREATORName: 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.

CREATOR – WHO CREATES THE SQUARE?

INFORMATION EXPERTName: 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?

INFORMATION EXPERT

How to distribute the responsibilities for obtain the sale’s total?

LOW COUPLINGName: 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.

HIGH COHESIONName: 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.

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.

GOF PATTERNS CLASSIFICATION

Table 1:  Design pattern space

Purpose Creational Structural Behavioral

Scope Class Factory Method Adapter InterpreterTemplate Method

Object Abstract Factory Adapter Chain of Responsibility

Builder Bridge Command

Prototype Composite Iterator

Singleton Decorator Mediator

Facade Memento

Proxy Flyweight

Observer

State

Strategy

Visitor

ABSTRACT FACTORY

Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Also Knows As: Kit

ABSTRACT FACTORY - MOTIVATION

ABSTRACT FACTORY - STRUCTURE

BUILDER

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

BUILDER

BUILDER

BUILDER

BUILDER

SIGLETON

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

SINGLETON

ADAPTER

ADAPTER

ADAPTER

ADAPTER

ADAPTER

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.

FACADE

FACADE

FACADE

FACADE

FACADE

Don’t ask!!!

BIBLIOGRAPHY 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.