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 ©

Download Report

Transcript 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 ©

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 preconditions 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
- companyName
- companyAddress
- companyRegistrationNumber
+ getCompanyInstance( )
+ getCompanyDetails( )
- Company( )
Class-scope
(or static) attribute
Class-scope
(or static) operation
Private constructor
The use of class-scope operations allows global access
© Bennett, McRobb and Farmer 2002
14
Creational Patterns: Singleton
Company
The operation
getCompanyDetails()
has been moved to the
subclasses where it is
polymorphically redefined
in each.
UKCompany
- companyInstance
- companyName
- companyAddress
+ getCompanyInstance( )
+ getCompanyDetails( )
- Company( )
The attribute
companyRegistrationNumber
has been moved to the
subclasses where it is defined
differently in each.
USACompany
FrenchCompany
- companyRegistrationNumber
- companyRegistrationNumber
- companyRegistrationNumber
+ getCompanyDetails( ):String
- UkCompany( ):UkCompany
+ getCompanyDetails( ):String
- USACompany( ):USACompany
+ getCompanyDetails( ):String
- 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
- singletonData
+ getInstance( )
+ getSingletonData( )
+ singletonOperation( )
- Singleton( )
Holds object identifier for
the Singleton instance
Returns object identifier
for the unique instance
Private constructor — only
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 objectoriented 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
play( )
addClip( )
removeClip( )
Delegates to
the play()
operation in
the
components.
getChild( )
play() is
polymorphically
redefined
1
*
*
VideoClip
SoundClip
play( )
play( )
© Bennett, McRobb and Farmer 2002
19
Composite applied to Agate
Advert
MediaClip
play( )
* {Ordered}
addClip( )
play()is
polymorphically
redefined
removeClip( )
getChild( )
1
VideoClip
SoundClip
AdSequence
mediaClipCollection
play( )
play( )
play( )
addClip( )
for all m in mediaClipCollection
m.play()
Collection of
MediaClip
object identifiers
removeClip( )
getChild( )
changeSequence( )
© Bennett, McRobb and Farmer 2002
Delegates to
the play()
operation in
the
components.
20
Composite Pattern
General Form
Client
Component
{Ordered}
*
anOperation( )
addComponent( )
anOperation()is
polymorphically
redefined
removeComponent( )
getChild( )
1
Leaf
OtherLeaf
Composite
componentCollection
anOperation( )
anOperation( )
anOperation( )
addComponent( )
for all c in componentCollection
c.anOperation()
Collection of
Component
object identifiers
removeComponent( )
getChild( )
© Bennett, McRobb and Farmer 2002
Delegates to
the anOperation()
operation in
the
components.
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( )
calcCosts( )
Contains the object identifier
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
C:Campaign
D:Campaign
:Completed
:Commissioned
E:Campaign
:Active
:Paid
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
operation( )
ConcreteStateB
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