Object-Oriented Software Engineering

Practical Software Development using UML and Java

Design Patterns – Part 2

Sources:
Chapter 6: Using Design Patterns, and
Chapter 30 (parts) Designing the Logical Architecture with Patterns
Craig Larman’s Text: Applying UML and Patterns, Chaps: 16, 22, & 23.
Grasp Pattern – The Controller Pattern
This GRASP Pattern is very useful for those developing web-
based applications, among other things.

Problem: Who should be responsible for handling an input system

‘event?’

So, first, what is a “system event?”

System Event – event generated by external actor.
Associated with system operations in response to a system event.

Example:
An actor may depress a button signifying End Sale, but this is
only used to indicate a desired system operation.

The ‘View’ certainly does NOT realize this request.

Rather, it is passed on to a controller.

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

Controller Pattern
Solution: Assign the responsibility for handling some kind
of event message to some kind of class representing one
of the following choices:

 A class that represents overall system, device, or

subsystem (façade controller)
or
 A class that represents a use case scenario within
which the system event occurs, often named
<usecasename> Handler, or <UseCaseName>
Coordinator or <UseCaseName> Session

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

Controller Pattern:
A Controller is a non-user interface object responsible for receiving or
handling a system event.

A Controller may represent a receiver of a signal or a handler of all

system events in a use case scenario.

Input events might come from

a GUI operated by a person, or
a call from a telecommunications switch, or
a signal from a sensor, etc.

(Note that classes such as window, applet, widget, view, document, etc. are not
used. These kinds of classes do not fulfill the tasks associated with system
events; rather, these typically receive events and delegate them to some kind of
controller.)

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

Controller Pattern: System Events
Most applications have ‘System Events.’
Typically the ‘system’ is modeled as a class during analysis
Consider: (Larman)
System

endSale()
enterItem()
makeNewSale()
makePayment()
…

Do not infer that there will be a class named System in Design.

Rather, during Design, a Controller class is assigned the responsibilities for
system operations.

Remember who is developing requirements and performing analysis…..

We simply do not know what the implementation (solution) will be at this time.

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

Controller:

Who is the Controller for System Events?

Presumably, there is an interface layer (a GUI, sensor

activation, other things…) that needs to send a message (a
system event message) to the application or domain layer

A Controller (coordinator…) is the class of object that is

responsible for receiving such a message and delegating the
follow-on work to other objects.

A Controller object in this context is often a kind of

‘façade’ onto the domain layer from an interface layer.

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

Controller - Discussion
In all cases, some kind of ‘Handler’ for these events must be chosen.

It is this Controller Pattern that provides some guidance for generally

acceptable suitable choices.

Again, a controller class is often some kind of façade into the

domain (application) layer from the interface (boundary) layer.

Often, we have a single controller for an entire use case,

If so, then the state of the use case is maintained in the Controller.

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

Controller - Discussion

We want to be careful to NOT give Controllers too much

responsibility.

Controller classes delegate work to other objects;

They coordinate / control the activity, but NOT do too
much of the work itself other than coordinating and
sequencing.

But remember, the Controller ‘knows’ where the Model

is and what is available to satisfy the system events.

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

Controller - Discussion

Several different kinds of Controllers.

Main two:
Façade controller, and
Use Case controller

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

Controllers – Categories: Façade Controller
This kind of controller in design may represent the system, a
device, or a subsystem, as we have stated.

Select some class name that suggests a ‘cover’ or façade over the
other layers of the application, and that provides the main point
of service calls from the UI layer down to other layers.

Again, it is a class that represents the entire software system or

subsystem.

Note: ‘Façade’ Controllers are used when there are not too
many events to control, and there is not sufficient need for
alternating controllers.

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

Controllers – Categories: Use Case Controller
Use Case Controllers – Usually a different controller for each use case

Note that a use case controller is NOT a domain object; in fact, it is a

fabrication used to handle events.

Consider switching to a use case controller when a façade controller

starts becoming too large and starts to lose cohesion and starts having
high coupling.

A use case controller is a good choice when there are a number of

system events across different processes; it factors their handling into
manageable classes and
Also forms the basis for knowing the state of the current scenario in
progress.

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

The Use Case Controller Pattern

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

Additional Controllers: Page and Front
Two other design patterns related to Use Case controllers:
Page Controller, and
Front Controller
In a Page Controller pattern, the controller uses a single Presenter
which interacts with the Model (the data for the page). When it receives
a request, the Page Controller can determine which partial View to
display within the page, and then interact with that View following the
MVP pattern.

In the Front Controller pattern, a separate controller examines

each request and determines which page to display. Each page is a
complete MVP implementation, with its own View, and each Presenter
interacts with the View and the Model (the data)

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

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

Model–View–Presenter (MVP) is a derivative of

the Model–View–Controller (MVC) software pattern,
also used mostly for building user interfaces.

In MVP the presenter assumes the functionality of the

"middle-man" (played by the controller in MVC).
Additionally, the view is responsible for handling the
UI events (like mouseDown, keyDown, etc), which
is normally the controller's job.
Eventually, the Model becomes strictly a 
domain model.

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

Presenter - more

MVP is a user interface design pattern engineered to facilitate

automated unit testing and improve the separation of concerns in
presentation logic:

The Model is an interface defining the data to be displayed or

otherwise acted upon in the user interface.

The View is an interface that displays data (the model) and routes
user commands (events) to the Presenter to act upon that data.

The Presenter acts upon the model and the view. It retrieves data
from repositories (the model), and formats it for display in the
view.

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

© Lethbridge/Laganière 2001 Chapter 6: Using design patterns 17
Connection to the UP
In the UP, we use the terms boundary, control, and entity classes.

Boundary objects are the abstractions of the interfaces;

Entity objects are the application-independent (and usually
persistent) domain software objects, and
Control objects are the use case handlers as described in the
Controller pattern.

Boundary Objects: We know from our study of the UP that

interface objects (e.g. windows or widgets) and the presentation layer
should NOT have the responsibility for fulfilling system events.

System operations should be handled by the application logic or

domain layers of objects rather than in the interface layer of a
system.

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

Connection to the UP – Read on your own
A Controller object is typically a client-side object within the same
process as the UI (for example, an application with a Java Swing
GUI), and so is not exactly applicable when the UI is a Web client
in a browser, and there is a server-side software involved.

In the latter case, there are various common patterns of handling

the system events that are strongly influenced by the chosen server-
side technical framework, such as Java servlets.

Nevertheless, it is a common idiom to create server-side use case

controllers with either a servlet for each use case or an Enterprise
JavaBeans (EJB) session bean for each use case.

The server-side session object represents a ‘session’ of interaction

with an external actor.

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

More details…Read on your Own
If the UI is not a web client (for example, it is a Swing or Windows
GUI), but the application calls on remote services, it is still common
to use the Controller pattern.
The UI forwards the request to the local client-side Controller, and
the Controller may forward all or part of the request handling on
to remote services.

This design lowers the coupling of the UI to remote services, and

makes it easier, for example, to provide the services either locally
or remotely, through the indirection of the client-side Controller.

To summarize, the Controller receives the service requests from the

UI layer and coordinates their fulfillment, usually by delegation to
other objects.

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

Thesis Topic

Testing Design Patterns with various architectures.

Comprehensive survey of design classes and appropriate

applications.

Lots of research possibilities with design patterns and

their various derivatives…

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

The Façade Pattern (Gang of Four) -5
• Context:
—Often, an application contains several complex packages.
- In Larman, a complex package may be: subsystem, package or complex
class.
—A programmer working with such packages has to manipulate many different
classes
• Problem:
—How do you simplify the view that programmers have of a complex package?
(again, ‘package’ is generic….)
—(Sometimes we have very large classes that users of these classes may incur
tremendous overhead. Is all the overhead necessary??)
• Forces:
— It is difficult for a programmer to understand / use an entire subsystem
— If several different application classes call methods of the complex package,
then any modifications made to the package will necessitate a complete
review of all these classes.

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

Façade Pattern (GofF) For Subsystem Packages:

• Here, the most common pattern of access is Façade, a GoF design pattern.

• We have a public façade object defining the services for the subsystem, and clients
collaborate with the façade, not internal subsystem components.

• The façade should not normally expose many low-level operations. Rather, it exposes
a small number of high-level operations – the coarse-grained services.

• A façade does not normally do its own work. Rather, it is consolidator or mediator to the
underlying subsystem objects, which do the work.

• The façade is a wrapper and single point of access into the ‘rules engine’ of a subsystem.

• Other packages do not see the implementation of the subsystem, as it is

hidden behind the façade.

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

Façade Pattern
Facade pattern: software engineering design pattern commonly used with OOP.
A facade is an object that provides a simplified interface to a larger body of code,
such as a subsystem or a class library.

Below: The façade class abstracts Packages 1,2, and 3 from the rest of the
application.
Clients use the façade pattern to access resources from the packages.
They are going to ‘doStuff’ with the objects c1, c2, and c3

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

Façade
• Another view: «Facade» «PackageClass1»
«PackageClass2»
«PackageClass3»

We create a special class called a <<Façade>>, which simplifies* the use of the package.
The Façade class simply contains a simplified set of public methods.
*
Result is the creation of a class containing the most often used / needed facilities in the
package. Thus other client elements desiring services of this complex
package can avail themselves of the Façade class, where it is likely what
services they want are simpler to acquire.

Since we are talking about a complex package, other clients that need some of the
complexities of the package can access these services as they normally would – via the
public interfaces of these other classes.

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

Façade
• Example: Airline * RegularFlight
<<façade>>
findFlight
makeBooking *
deleteBooking Person

Airline reservation systems have many classes and methods.

Some design elements, like subsystems, may need to interact with the airline system but
don’t want to be exposed to any changes that might be made to it (via dependencies).

So, we can define and Airline class to be a <<Façade>> that contains methods (access) to
the most important query and booking operations in other classes in the airline system.

Thus any dependency arising from this relation is only on the Façade class.

Here, above, via the Airline façade class, we have access to two other classes from other
likely complex packages

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

The Singleton Pattern (Gang of Four) 3

• 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. But there must be only one!
© Lethbridge/Laganière 2001 Chapter 6: Using design patterns 27
Singleton
«Singleton»
- theInstance
Have a private class variable, getInstance
possibly called, ‘theInstance.’
This stores the instance.
Company
Then have a public class method if (theCompany==null)
theCompany theCompany= new Company();
(static method) possibly called,
‘getInstance.’ Company «private»
getInstance return theCompany;

First time method is called, it creates Here, Company class may embody several

a single instance (object) and stores it in important characteristics of the Company

theInstance.. Subsequent calls simply
return theInstance.
A private Constructor, which ensures
no other class will be able to create
an instance of the singleton class is
needed.
(operations and attributes).
The public class method getInstance() makes
this instance globally accessible. (it returns
theinstance).
Note: effectively, the Singleton instance is
effectively a global variable. Minimize these.

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

Controversy

There is criticism of the use of the singleton pattern, as

some consider it an anti-pattern, judging that it is
overused, introduces unnecessary restrictions in
situations where a sole instance of a class is not
actually required, and introduces global state into an
application

The Abstract Factory, Builder, and Prototype patterns can

use Singletons in their implementation.

Façade objects are often Singletons because only one

Façade object is required.
© Lethbridge/Laganière 2001 Chapter 6: Using design patterns 29