Chapter 6: Using Design Patterns Part 1

Object-Oriented Software EngineeringPractical Software Development using UML and Java

Chapter 6:

Using Design Patterns

Part 1

© Lethbridge/Laganière 2001 Chapter 6: Using design patterns 2

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 andcreate 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).


6.1 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

We will only look at a few.


Pattern description

Context: • The general situation in which the pattern applies

Problem: —A short sentence or two raising the main difficulty.

Forces: • The issues or concerns to consider when solving the problem

Solution: • The recommended way to solve the problem in the given context.

— ‘to balance the forces’

Antipatterns: (Optional)• Solutions that are inferior or do not work in this context.

Related patterns: (Optional) • Patterns that are similar to this pattern.

References:• Who developed or inspired the pattern.


Remember: our patterns define a relation between

a certain context

a problem

a solution

Patterns represent well-known knowledge

Really documents common practice

Patterns should be in the public domain

Patterns need to be written for the public good.


6.2 The Abstraction-Occurrence Pattern

• Context: — Often found in class diagrams that form part of the system

domain model.—Often in a domain model you find a set of related objects

(occurrences).—The members of such a set share common information but also

differ from each other in important ways. (Sports cars ….)• Problem:

—What is the best way to represent such sets of occurrences in a class diagram? Use the commonality, yet represent the differences!

• Forces: —You want to represent the members of each set of occurrences

without duplicating the common information. - Cannot have this!

—Want to maximize the flexibility of the system too.


Abstraction-Occurrence

• Solution:

TVSeries

seriesNameproducer

Episode

numbertitlestorySynopsis

******

«Occurrence»«Abstraction» ******

Title

nameauthor

LibraryItem

barCodeNumber******

isbnpublicationDatelibOfCongress

Note: create an abstraction containing common data to all occurrences.This is the “abstraction”. Then create the “occurrence” class that represents instances (occurrences) of the abstraction. Realtionship is 1:*ForeignSportsCar { CarMake; CountryofOrigin…} Auto { Model, Style, Cost..}Note (as we shall see) this is not inheritance.

Remember (Java): anInterface can have NO implementations; may at most have constants;Abstract Class has at least one abstract method; can have declarations.


Abstraction-Occurrence Antipatterns:

nameauthor

LibraryItem

barCodeNumber


Title

nameauthor

LibraryItem

barCodeNumber


nameauthor

LibraryItem

barCodeNumber


GulliversTravels MobyDick

Single class: Bad because info would have to be duplicated in each occurrence – and same info would be in each occurrence!

Here, separate subclass for each title.All other information would have to be duplicated in each instance.Also, want to be able to add new books without programming new classes!

Problem here is making the abstract class a super class of the occurrence.Attributes would beinherited, of course, butdata would be lost! We’d have to fill in name, author … for each occurrence!


Abstraction-Occurrence

Square variantScheduledTrain

number

SpecificTrain

date**

* *

ScheduledLeg SpecificLeg

actualDepTime*

actualArrTimescheduledDepTimescheduledArrTime

Station

origin destination* *

All we are saying here is that if the abstraction itself is an aggregate (note ScheduledTrain and ScheduledLeg) the occurrences also are usually aggregates (SpecificTrain; SpecificLeg). Read more on this on your own.


6.3 The General Hierarchy Pattern

• Context: - —Occurs in MANY class diagrams.—Objects in a hierarchy can have one or more objects above

them (superiors), and one or more objects below them (subordinates).

—Some objects cannot have any subordinates • Problem:

—How do you represent a hierarchy of objects, in which some objects cannot have subordinates?

• Forces: —You want a flexible way of representing the hierarchy

- that prevents certain objects from having subordinates- yet, where all the objects have many common properties and

operations

• Main Thought: All hierarchies are NOT necessarily inheritance hierarchies!!!!


General Hierarchy

• Solution: «subordinate»*«Node»

«SuperiorNode»«NonSuperiorNode»

* supervises

Manager

Employee

TechnicianSecretary

0..1

0..1

* contains

Directory

FileSystemItem

File

0..1

Create an abstract <<Node>> class that represents features possessed by all – like on that each node can have a superior class.


General Hierarchy



* supervises

Manager

Employee

TechnicianSecretary

0..1

0..1

* contains

Directory

FileSystemItem

File

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.


General Hierarchy



* supervises

Manager

Employee

TechnicianSecretary

0..1

0..1

* contains

Directory

FileSystemItem

File

0..1

The multiplicity of the <<subordinates>> association can be optional-to-many or many-to-many.If many-to-many, then the hierarchy of instances becomes a lattice, in which a node can have manysuperiors. The ‘optional’ allows for the case of the top node in the hierarchy, which has no superiors.


General Hierarchy

• Examples:

* supervises

Manager

Employee

TechnicianSecretary

0..1

* contains

Directory

FileSystemItem

File

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.


General Hierarchy

Antipattern:

RockRecordingBluesRecordingClassicalRecordingJazzRecordingMusicVideo

VideoRecoding AudioRecording

Recording

Don’t fall into the trap of thinking a hierarchy of categories is necessarily a hierarchy of classes!


6.4 The Player-Role Pattern

• Context: (More issues with Generalization…) An object may play different roles in different

contexts. Want to model class diagrams for this!—Pattern used to solving modelling problems when

you are drawing many different types of class diagrams.

—A role is a particular set of properties associated with an object in a particular context.

• Problem: —How do you best model players and roles so that a

player can change roles or possess multiple roles?


Player-Role

• Forces:

—It is desirable to improve encapsulation by capturing the information associated with each separate role in a class.

—You want to avoid multiple inheritance. —You cannot allow an instance to change class

• Solution:«Player»

«Role1» «Role2»

«AbstractRole»

Create a <<Player>> class to represent the object that plays different roles. Create an association from this class to an abstract <<Role>> class, which is a superset of all possible roles. The subclasses of this <<Role>> class encapsulate all the properties and behaviors associated with the different roles. (Recall abstract classes can have ‘some’ behaviors and can have declarations).

1 *


Player-Role

«Player»

«Role1» «Role2»

«AbstractRole»

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.

<<Role>> can be an Interface – but normally a Role contains a mechanism inherited by its subclasses, allowing them to access information about the <<Player>>.So make <<Role>> an interface only if this mechanism is not needed (cannot implement methods or have declarations in an interface (other than constants).

1 *


Player-Role

Example 1:

Animal HabitatRole

habitattypeOfFood

OmnivoreHerbivore LandAnimalAquaticAnimal

0..2

Carnivore

Note the two roles of animals: role based on: type of food, habitat.Idea behind these roles is that an animal may have to switch from one role to another. We don’t want to have to model this situation by destroying one class and creating another class – or opposite.Could make habitat an attribute of HabitatRole and omit two subclasses.But then we lose the advantage of polymorphism for any operations that would differ in Aquatic Animal and Land Animal.

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.


Player-Role

Example 2:LevelRole

attendance

PartTimeStudentFullTimeStudent UndergraduateStudentGraduateStudent

level

StudentAttendanceRole

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 polymorphismand is responsive to any changes in role the Student might take, whether these changes be in attendance or in level (or both).


Player-Role

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.


6.5 The Singleton Pattern

• 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


Singleton

• Solution:

Company

theCompany

Company «private»getInstance

if (theCompany==null) theCompany= new Company();

return theCompany;

«Singleton»

theInstance

getInstanceHave a private class variable, possibly called, ‘theInstance.’ This stores the instance.

Then have a public class method(static method) possibly called,‘getInstance.’

First time method is called, it creates Here, Company class may embody several a single instance and stores it in important characteristics of the Company theInstance.. Subsequent calls simply (operations and attributes). return theInstance.

The public class method getInstance() makesA private Constructor, which ensures this instance globally accessible. no other class will be able to create an instance of the singleton class is Note: effectively, the Singleton instance is needed. effectively a global variable. Minimize these.


6.6 The Observer Pattern

• Second in the gang-of-four patterns (Singleton was the first)• This is another VERY popular one.• Context:

—When you have a two-way association is created between two classes, the code for the classes becomes inseparable.

—If you want to reuse one class, then you also have to reuse the other. There is a dependency.

• Problem: —How do you reduce the interconnection between classes,

especially between classes that belong to different modules or subsystems?

• Forces: —You want to maximize the flexibility of the system to the

greatest extent possible


Observer• Solution:

So, what do we do? We create an abstract class we will call <<Observable>> that maintains a collection of <<Observer>> instances.

<<Observable>> class is very simple; it merely has a mechanism to add and remove observers as well as a method, notifyObservers, that sends an update message to each <<Observer>>.

Any application class can declare itself to be a subclass of the <<Observable>> class.

In Java, we call these ‘listeners.’

* ******

«ConcreteObservable» «ConcreteObserver»

«Observable»

addObservernotifyObservers

«interface»«Observer»

update

*****


Observer• Solution:

WeatherViewer

* ******

Observers are notified when a new prediction is readyForecaster

Observable


«Observable»



update

* ****** «interface»Observer

<<Observer>> is an interface, defining only an abstract update method.

Any class can thus be made to observe an <<Observable>> by declaring that it implements the interface, and by asking to be a member of the observer list of the <<Observable>>.

The <<Observer>> can then expect a call to its update method whenever the <<Observable>> changes.

Using this pattern, the <<Observable>> neither has to know the nature of the number of classes that will be interested in receiving an update messages nor what they will do with this information.


Observer• Example:

WeatherViewer

* ******

Observers are notified when a new prediction is readyForecaster

Observable


«Observable»



update

* ****** «interface»Observer

Java has an Observer interface and an Observable class. This is a specificimplementation of this pattern.

Consider: a ‘forecast’ requires a lot ofcomputations. Once done, it ‘notifies’ all interested instances.

Forecaster is thus an observable object.

One observer object might be an interface object responsible for displaying weather forecast; another might be dependent on weather information to plan a schedule..

Observer pattern in widely used to structure software cleanly into relatively independent modules. It is the basis of the MVC architecture.

Just a class…

Chapter 6: Using Design Patterns Part 1

Documents

Transcript of Chapter 6: Using Design Patterns Part 1