DESIGN PATTERNSBreno Batista Machado

Weslei A. de T. Marinho

TALK OUTLINE

Pattern Definition GoF Patterns

GoF Patterns Classification Creational Patterns Structural Patterns Behavioral Patterns

Architectural Patterns Idioms

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.

TYPES OF PATTERNS

• Architectural Patterns• Design Patterns• Idioms

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

BASIC PATTERN METAMODEL

Problem Solution

Consequence

Pattern

name

*

THE SACRED ELEMENTS OF THE FAITH

FMFactory Method

107

PTPrototype

117

AFAbstract Factory

87

BUBuilder

97

SSingleton

127

CPComposite

163

PXProxy

207

AAdapter

139

DDecorator

175

FAFacade

185

BRBridge

151

The role structure

FLFlyweight

195

CRChain of

Responsibility

223

TMTemplateMethod

325

SRStrategy

315

CDCommand

233

MMMemento

283

MDMediator

273

STState

305

OObserver

293

ITIterator

257

INInterpreter

243

VVisitor

331

The role behaviors

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

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

TEMPLATE METHOD

Intent: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine steps of an algorithm changing the algorithm’s structure.

TEMPLATE METHOD

Motivation: Think about to prepare coffee and tea.

TEMPLATE METHOD

Structure

TEMPLATE METHOD

Structure

TEMPLATE METHOD

Consequences: Template Method prove code reuse It lead to an inverted control structure: “the

Hollywood principle” that says “Don’t call us, we’ll call you.”

OBSERVER

Intent: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Also Know As: Dependents, Publish-Subscribe

Motivation: Maintain a consistency between objects in a system that is partitioned into a collection of cooperating classes.

OBSERVER

OBSERVER

OBSERVER

Consequences: Support for broadcast communication Unexpected updates

ARCHITECTURAL PATTERNS

It expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

ARCHITECTURAL PATTERNS

We’ll see… Layers Model View Controller

LAYERS

It helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.

Example: Networking Protocols.

Context: A large system that requires decomposition.

LAYERS

StructureIndividual Layer Layers collaborating

LAYERS

Consequences: Reuse of layers Support for standardization Dependencies are kept local Exchangeability Cascades of changing behavior Lower efficiency Difficulty of establishing the correct granularity of

layers

MODEL-VIEW-CONTROLLER

It divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Example: A system for political elections with

many representations. Context: Interactive applications with a flexible human-computer interface

MODEL-VIEW-CONTROLLERStructure

MODEL-VIEW-CONTROLLERStructure

MODEL-VIEW-CONTROLLER

Consequences: Multiple views of the same model Synchronized views “Plugglable” views and controllers Increased complexity Potential for excessive number of updates Intimate connection between view and controller Close coupling of views and controller to a model

IDIOMS

Idioms are low-level patterns specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them with the features of the giver language.

Idioms provides a help to solve some recurring problem with a programming language. Ex. Memory management, object creation, naming of methods, source cod formatting and so on.

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.