Scribd
Upload
43 views

Design Patterns: Weslei A. de T. Marinho

Patterns are a means of documenting software architectures. A pattern addresses a recurring design problem and presents a solution to it. GRASP stands for general responsibility assignment software pattern.

Uploaded by

studentscorners
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
43 views

Design Patterns: Weslei A. de T. Marinho

Patterns are a means of documenting software architectures. A pattern addresses a recurring design problem and presents a solution to it. GRASP stands for general responsibility assignment software pattern.

Uploaded by

studentscorners
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 41

DESIGN PATTERNS

Weslei 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

Pattern
Problem Solution
name

Consequence
GOF PATTERN METAMODEL
ExampleDomai
SampleCode Intent
n *
*
A.K.
A *

relPatterns
* Issues
Pattern
*
name

Motivation classificati Implementation Consequen


(ExampleScenario) on Issue ce

* Participant
Applicability * *
(Problem)
Structure
(SolutionGraphicalDescription
) ClassDiagram

BehavioralStructure StaticStructure ObjectDiagram


(Collaboration)
GRASP PATTERNS
• GRASP stands for General Responsibility
Assignment Software Pattern

• Will be presented the following GRASP


Patterns:
– Information Expert
– Creator
– Low Coupling
– High Cohesion
CREATOR
Name: Creator
Problem: Who creates an A?
Solution: (this can be Assign class B the
viewed as advice) 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 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?
INFORMATION EXPERT

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


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.
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.
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
  Purpose
Creational Structural Behavioral
Scope Class Factory Method Adapter Interpreter
Template 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

Table 1: Design pattern space


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.

You might also like