SEG 2100 Software Design II

1
Using Design Patterns
2
Introduction To Patterns

• The recurring aspects of designs are called
  design patterns.
• A pattern is the outline of a reusable solution
  to a general problem encountered in a particular
  context.
• Many of them have been systematically documented
  for all software developers to use.
• A good pattern should
• Be as general as possible.
• Contain a solution that has been proven to
  effectively solve the problem in the indicated
  context.
• Studying patterns is an effective way to learn
  from the experience of others.

3
How Patterns Are Described

• Context
• The general situation in which the pattern
  applies.
• Issues
• The issues or concerns to consider.
• Antipatterns (Optional)
• Intermediate solutions that do not completely
  solve the problem.
• Solution
• The recommended way to solve the problem.

4
The Abstraction-Occurrence Pattern

• Context
• A class has a set of objects (Occurrences).
• The objects have a set of common features, for
  example
• A set of attributes have the same value over all
  of the objects.
• But the objects differs from each other in
  important ways.
•  Issues
• You want to represent the members of each set of
  occurrences without duplicating the common
  information.

5
Abstraction-Occurrence Example 1
Class Diagram
Instance Diagram
Account
intRate
monthlyFee
checksAllowed
insuranceAvailable
number
balance
creditOrOverdraftLimit
CheckingAccount
MortgageAccount
CreditCardAccount
collateralProperty
expiryDate

• The objects have a set of common attributes that
  have the same value.
• The objects also have another set of attributes
  that have different values
• number, balance, and creditOrOverdraftLimit.
• How can the members of the set of occurrences be
  represented without duplicating the common
  information?

6
Abstraction-Occurrence Example 1Anti-Pattern
1
Make these attributes static.

• Make the common attributes static.
• This way there is only one value for each
  attribute, and the objects see the same value.

7
Abstraction-Occurrence Example 1Anti-Pattern
1
There is duplication within a set, but not across
different sets.

• Class variables wont work b/c other types of
  accounts, such as MortgrageAccount, have
  different values for the attributes.

8
Abstraction-Occurrence Example 1Solution
9
Abstraction-Occurrence Example 2
Class Diagram
Instance Diagram
LibraryItem
name
author
isbn
publicationDate
barCodeNumber

• The objects have a set of common attributes that
  have the same value.
• The objects also have another set of attributes
  that have different values
• barCodeNumber.
• How can the members of the set of occurrences be
  represented without duplicating the common
  information?

10
Abstraction-Occurrence Example 2Solution
11
Abstraction-Occurrence Example 3Solution
12
Abstraction-Occurrence Example 4Scheduled
Train
The scheduled time of a particular leg is the
same for every specific date occurrence of the
train
13
Abstraction-Occurrence Example 4Scheduled
Train (Anti-pattern 1)
Why is this a bad design?

• Because
• memory duplication
• variable of legs
• variable of stations

14
Abstraction-Occurrence Example 4Scheduled
Train (Anti-pattern 2)
Why is this an inferior design?

• Because
• number is duplicated
• for every day occurrence of the train.

• And
• Scheduled times are duplicated for very day
  occurrence of the train.

15
Abstraction-Occurrence Example 4Scheduled
Train (The Solution)
16
Abstraction-Occurrence Example 4Scheduled
Train (An Instance Diagram)
17
The General Hierarchy Pattern

• Context
• An instance diagram appears as a hierarchy.
• An object in the hierarchy has links to
• One or more objects above it (superiors).
• One or more objects below it (subordinates).
• Some objects cannot have any subordinates.
• Issues
• The connections between objects represent links
  of association.
• The connections do not represent inheritance.

18
The General Hierarchy Pattern(Solution)
19
General Hierarchy Pattern Example 3
AV
Class Instance
20
The Player-Role Pattern

• Context
• An object may play different roles in different
  contexts.
• An object may need to change roles.
• Issues
• It is desirable to improve encapsulation by
  keeping information related to only one role in
  one class.

21
Player-Role Pattern Example 1(Context)
22
Player-Role Pattern Example 1 (Anit-pattern)
23
Player-Role Pattern Example 1(Solution)
24
Player-Role Pattern Example 2(Solution)
25
Player-Role Pattern General Solution