0% found this document useful (0 votes)
22 views32 pages

Chapter 15

Uploaded by

unstable da
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
22 views32 pages

Chapter 15

Uploaded by

unstable da
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 32

Design Patterns

Based on Chapter 15 of Bennett, McRobb


and Farmer:
Object Oriented Systems Analysis and
Design Using UML, (2nd Edition), McGraw
Hill, 2002.
03/12/2001 © Bennett, McRobb and Farmer 2002 1
In This Lecture You Will
Learn:
 What types of patterns have been
identified in software development
 How to apply design patterns during
software development
 The benefits and difficulties that may
arise when using patterns

© Bennett, McRobb and Farmer 2002 2


Patterns vs. Frameworks
 Frameworks are partially completed
software systems that may be targeted
at a specified type of application
 However patterns
– are more abstract and general than
frameworks
– cannot be directly implemented in a
particular software environment
– are more primitive than frameworks

© Bennett, McRobb and Farmer 2002 3


Catalogues & Languages
 A pattern catalogue is a group of
patterns that are related to some
extent and may be used together
or independently of each other
 The patterns in a pattern language
are more closely related, and work
together to solve problems in a
specific domain
© Bennett, McRobb and Farmer 2002 4
Key Principles
 Key principles that underlie patterns
– abstraction
– encapsulation
– information hiding
– modularization
– separation of concerns

© Bennett, McRobb and Farmer 2002 5


Key Principles
– Coupling and cohesion
– Sufficiency
– Completeness and primitiveness
– Separation of policy and implementation
– Separation of interface and
implementation
– Single point of reference
– Divide and conquer
Buschmann et al. (1996)

© Bennett, McRobb and Farmer 2002 6


Non-functional Properties
 Buschmann et al. (1996) identify
the important non-functional
properties of a software
architecture
 changeability
 interoperability
 efficiency
 reliability
 testability
 reusability
© Bennett, McRobb and Farmer 2002 7
Pattern Template
 Name—meaningful that reflects the knowledge
embodied by the pattern
 Problem—description of the problem that the
pattern addresses (the intent of the pattern).
 Context—represents the circumstances or precon-
ditions under which it can occur.
 Forces—embodied in a pattern are the constraints
or issues that must be addressed by the solution
 Solution—description of the static and dynamic
relationships among the components of the
pattern
© Bennett, McRobb and Farmer 2002 8
Other Aspects of Templates
 An example of the use of a pattern
that serves as a guide to its
application
 The context that results from the
use of the pattern
 The rationale that justifies the
chosen solution
 Related patterns
© Bennett, McRobb and Farmer 2002 9
Other aspects of Templates
 Known uses of the pattern that validate it
(Some suggest that until the problem and
its solution have been used successfully at
least three times—the rule of three—they
should not be considered as a pattern)
 A list of aliases for the pattern (‘also
known as’ or AKA)
 Sample program code and implementation
details (commonly used languages include
C++, Java and Smalltalk)

© Bennett, McRobb and Farmer 2002 10


GOF Design Patterns
 Catalogue of 23 design patterns presented
by Gamma et al. (1995) patterns known as
Gang of Four—hence GOF Patterns
 Classifies patterns as creational, structural
or behavioural
 Typically address issues concerning
changeability, and involve several different
aspects: maintainability, extensibility,
restructuring and portability

© Bennett, McRobb and Farmer 2002 11


Creational Patterns
 Concerned with the construction of
object instances
 Separate the operation of an
application from how its objects
are created
 Gives the designer considerable
flexibility in configuring all aspects
of object creation
© Bennett, McRobb and Farmer 2002 12
Creational Patterns:
Singleton
 How does one ensure that only one
instance of the company class is
created?
Company

companyName
companyAddress
companyRegistrationNumber

getCompanyDetails( )

© Bennett, McRobb and Farmer 2002 13


Creational Patterns:
Singleton
 Solution—restrict access to the
constructor!
Company

- companyInstance Class-scope
- companyName (or static) attribute
- companyAddress
- companyRegistrationNumber Class-scope
+ getCompanyInstance( ) (or static) operation
+ getCompanyDetails( )
- Company( ) Private constructor

The use of class-scope operations allows global access


© Bennett, McRobb and Farmer 2002 14
Creational Patterns:
Singleton
Company
- companyInstance
The operation - companyName
getCompanyDetails() - companyAddress The attribute
has been moved to the + getCompanyInstance( ) companyRegistrationNumber
subclasses where it is + getCompanyDetails( ) has been moved to the
polymorphically redefined - Company( ) subclasses where it is defined
in each. differently in each.

UKCompany USACompany FrenchCompany

- companyRegistrationNumber - companyRegistrationNumber - companyRegistrationNumber

+ getCompanyDetails( ):String + getCompanyDetails( ):String + getCompanyDetails( ):String


- UkCompany( ):UkCompany - USACompany( ):USACompany - FrenchCompany( ):FrenchCompany

•Different subclasses of Company can be instantiated


as needed, depending on run-time circumstances
© Bennett, McRobb and Farmer 2002 15
Creational Patterns:
Singleton

Singleton

- uniqueInstance Holds object identifier for


the Singleton instance
- singletonData
+ getInstance( ) Returns object identifier
for the unique instance
+ getSingletonData( )
+ singletonOperation( ) Private constructor — only
- Singleton( ) accessible via getInstance()

General form of Singleton pattern

© Bennett, McRobb and Farmer 2002 16


Structural Patterns
 Concerned with the way in which
classes and objects are organized
 Offer effective ways of using
object-oriented constructs such as
inheritance, aggregation and
composition to satisfy particular
requirements

© Bennett, McRobb and Farmer 2002 17


Structural Patterns:
Composite
• How can we present the same interface for
a media clip whether it is composite or not?

MediaClip

play( )

VideoClip SoundClip

play( ) play( )

© Bennett, McRobb and Farmer 2002 18


Structural Patterns:
Composite
How can we incorporate composite structures?
AdSequence
Delegates to
play( ) the play()
operation in
addClip( ) the
removeClip( ) components.

getChild( )
1
play() is
polymorphically
redefined

* *

VideoClip SoundClip

play( ) play( )

© Bennett, McRobb and Farmer 2002 19


Composite applied to Agate
Advert MediaClip

play( ) * {Ordered}

addClip( )
play()is removeClip( )
polymorphically
redefined getChild( )

1
VideoClip SoundClip AdSequence Collection of
MediaClip
mediaClipCollection
object identifiers
play( ) play( ) play( )
addClip( ) Delegates to
for all m in mediaClipCollection the play()
removeClip( ) operation in
m.play() the
getChild( ) components.
changeSequence( )
© Bennett, McRobb and Farmer 2002 20
Composite Pattern
General Form
Client Component
{Ordered}

anOperation( ) *

addComponent( )
anOperation()is removeComponent( )
polymorphically
redefined getChild( )

1
Leaf OtherLeaf Composite Collection of
Component
componentCollection
object identifiers
anOperation( ) anOperation( ) anOperation( )
addComponent( ) Delegates to
for all c in componentCollection the anOperation()
removeComponent( ) operation in
c.anOperation() the
getChild( ) components.
© Bennett, McRobb and Farmer 2002 21
Behavioural Patterns
 Address the problems that arise
when assigning responsibilities to
classes and when designing
algorithms
 Suggest particular static
relationships between objects and
classes and also describe how the
objects communicate
© Bennett, McRobb and Farmer 2002 22
Behavioural Patterns: State
 Consider the class Campaign.
 It has four states—Commissioned,
Active, Completed and Paid
 A Campaign object has different
behaviour depending upon which state
it occupies
 Operations have case statements giving
this alternative behaviour
 The class factored into separate
components —one for each of its states
© Bennett, McRobb and Farmer 2002 23
Behavioural Patterns: State
Campaign CampaignState
currentStateIdentifier
addAdvert( ) addAdvert( )

changeState( ) calcCosts( )
Contains the object identifier
calcCosts( )
of the current state object

Commissioned Active Completed Paid

addAdvert( ) addAdvert( ) addAdvert( ) addAdvert( )


calcCosts( ) calcCosts( ) calcCosts( ) calcCosts( )

State pattern applied to the class Campaign

© Bennett, McRobb and Farmer 2002 24


Behavioural Patterns: State

A:Campaign D:Campaign
C:Campaign

:Completed
:Commissioned

:Active :Paid

E:Campaign B:Campaign F:Campaign

Some State pattern objects for Agate – note


that there are 6 Campaign objects sharing the
four State objects.
© Bennett, McRobb and Farmer 2002 25
General form of State
Pattern

Context State

operation( ) operation( )

ConcreteStateA ConcreteStateB

operation( ) operation( )

© Bennett, McRobb and Farmer 2002 26


Before Using Patterns
 Before using a pattern to resolve
the problem ask
– Is there a pattern that addresses a similar
problem?
– Does the pattern trigger an alternative
solution that may be more acceptable?
– Is there a simpler solution? Patterns should
not be used just for the sake of it

© Bennett, McRobb and Farmer 2002 27


Before Using Patterns
– Is the context of the pattern consistent with
that of the problem?
– Are the consequences of using the pattern
acceptable?
– Are there constraints imposed by the
software environment that would conflict
with the use of the pattern?

© Bennett, McRobb and Farmer 2002 28


Using Patterns
 After selecting a suitable pattern
1. Read the pattern to get a complete
overview
2. Study the Structure, Participants and
Collaborations of the pattern in detail
3. Examine the Sample Code to see an
example of the pattern in use

© Bennett, McRobb and Farmer 2002 29


Using Patterns
4. Choose names for the pattern’s
participants (i.e. classes) that are
meaningful to the application
5. Define the classes
6. Choose application specific names for the
operations
7. Implement operations that perform the
responsibilities and collaborations in the
pattern

© Bennett, McRobb and Farmer 2002 30


Summary
In this lecture you have learned
about:
 What types of patterns have been
identified in software development
 How to apply design patterns during
software development
 The benefits and difficulties that may
arise when using patterns
© Bennett, McRobb and Farmer 2002 31
References
 Gamma et al. (1995)
(For full bibliographic details, see
Bennett, McRobb and Farmer)

© Bennett, McRobb and Farmer 2002 32

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy