Professional Documents
Culture Documents
Chapter 6:
Using Design Patterns
Part 1
Preview:
• Want to look at more class diagrams – static.
• But we want to look at recurring groupings of classes
that are regularly used to address common
problems.
• Want to take advantage of experiences of others and
create a better, more resilient design.
• Want to use
patterns that assist us in separating concerns (abstraction-
occurrence, observer, player-role);
patterns used to better create class hierarchies of instances;
patterns in which one method simply calls another method
in another class (have you seen this??);
patterns where you use delegation to gain access to facilites
in one or more other classes (Adaptor, Façade,
Proxy);
patterns that help protect other objects from unanticipated access
(immutable and read-only interfaces).
Square variant
ScheduledTrain SpecificTrain
*
number date
* *
ScheduledLeg SpecificLeg
*
scheduledDepTime actualDepTime
scheduledArrTime actualArrTime
* *
origin destination
Station
«Node» *
• Solution: «subordinate»
0..1
«NonSuperiorNode» «SuperiorNode»
0..1 0..1
Create an abstract <<Node>> class that represents features possessed by all – like on that each
node can have a superior class.
«Node» *
• Solution: «subordinate»
0..1
«NonSuperiorNode» «SuperiorNode»
0..1 0..1
Then create at least two subclasses of the <<Node>> class. One of the subclasses <<SuperiorNode>>
must be linked by a <<subordinates>> association to the superclass; whereas at least one
subclass <<NonSuperiorNode>> must not be. The subordinates of <<SuperiorNode>> can thus
be instances of either SuperiorNode or NonSuperiorNode.
«Node» *
• Solution: «subordinate»
0..1
«NonSuperiorNode» «SuperiorNode»
0..1 0..1
• Examples:
Employee * supervises FileSystemItem * contains
0..1 0..1
Here, we have three types of employees in the organization: only managers can supervise subordinates.
So, All are employees and inherit from Employee class. An employee has zero or one managers (manager
- as an employee - may not have a manager). Manager may supervise many
employees. Secretaries and Technicians cannot have subordinates; manager can.
In the second examle, FileSystemItem is the superiorclass. File and Directory inherit from FileSystemItem.
Only Directories can contain other file system objects, and this is described by the * relationship – a
directory may contain any number of file system items, but a file system item is contained in 0 or 1
directory. Where this is powerful is that both the File and the Directory inherit from FileSystemItem, yet
one of the subordinates can contain instances of the superclass.
Antipattern:
Recording
VideoRecoding AudioRecording
• Problem:
—How do you best model players and roles so that a
player can change roles or possess multiple roles?
«Role1» «Role2»
If the <<Player>> can only play one role at a time, the multiplicity between
<<Player>> and <<Role>> is one-to-one; otherwise it will be one-to-many.
typeOfFood habitat
Here, an animal may have a varying number of roles: aquatic, land-based or both.
Can also have used a role to capture whether animal is carnivore, herbivore or omnivore.
Example 2:
AttendanceRole Student LevelRole
attendance level
Here, we have two separate <Role>> superclasses. In one, student is characterized by his/her
attendance status and by whether or not s/he is a graduate student (or not)..
Both of these statuses can changed during the life of the Student object. This pattern, therefore,
makes it possible to represent a full or part time graduate or undergraduate student.
Here, modeling Student in this manner is much better and flexible. It supports polymorphism
and is responsive to any changes in role the Student might take, whether these changes be
in attendance or in level (or both).
Confusing in spots:
All this can be confusing. For example, it appears that the player-
role could be an abstraction-observer pattern. Certainly has
similar structure.
Player has many roles associated with it just like the abstraction
has many occurrences.
But there is a major difference:
In the Abstraction-Occurrence pattern, an abstraction is
… abstract, while its occurrences ten to be real-work things, such
as copies of books, or autos
In the Player-Role pattern, just the opposite is true, where
the player is normally the real-world entity (e.g. a person) while its
roles are abstractions.
• Context:
—It is very common to find classes for which only one
instance should exist (singleton)
- Examples: a Main Window; Company or University class.
• Problem:
—How do you ensure that it is never possible to create
more than one instance of a singleton class?
• Forces:
—The use of a public constructor cannot guarantee that
no more than one instance will be created.
—The singleton instance must also be accessible to all
classes that require it
getInstance
Have a private class variable,
possibly called, ‘theInstance.’
This stores the instance.
Company
if (theCompany==null)
Then have a public class method theCompany theCompany= new Company();
(static method) possibly called, Company «private»
‘getInstance.’ getInstance return theCompany;
First time method is called, it creates Here, Company class may embody several
Any application class can declare itself to be a subclass of the <<Observable>> class.