Software Engineering II

Design Patterns
(Adapter, Façade, Read Only Interface,
Abstraction Occurrence)

Dr. Abeer Hamdy

Lecture Objectives:

▪ Pattern Templates.

▪ Introduce the following Structural patterns:

▪ Adapter Pattern
▪Convert programming interface of one class into another
▪ Façade Pattern
▪ Defines a higher level interface that makes subsystems
easier to use.
▪ Read-only interface Pattern
▪To give privileges to some classes to be able to modify
attributes of objects that are otherwise immutable.
▪ Abstraction-Occurrence Pattern (Not GOF)
Pattern Forms: 1. Alexandrian template
▪ Pattern name
—meaningful name
▪ Problem
—the statement of the problem
▪ Context
—a situation giving rise to a problem
▪ Forces
—description of relevant forces and constraints
▪ Solution
—proven solution to the problem
▪ Examples
—sample applications of the pattern
Pattern Forms: 1. Alexandrian template

▪ Resulting context
—the state of the system after pattern has been applied
▪ Rationale
— explanation of steps or rules in the pattern
▪ Related patterns
▪ Known use
—occurrence of the pattern and its application within
existing system
Pattern Forms: 2. GOF template

▪ Pattern name and classification

▪ Intent
—what does the pattern do
▪ Also known as
—other known names of pattern (if any)
▪ Motivation
—the design problem
▪ Applicability
—situations where pattern can be applied
▪ Structure
—a graphical representation of classes in the pattern
Pattern Forms: 2. GOF template
▪ Participants
—the classes/objects participating and their responsibilities
▪ Collaborations
—of the participants to carry out responsibilities
▪ Consequences
—trade-offs, concerns
▪ Implementation
—hints, techniques
▪ Sample code
—code fragment showing possible implementation
▪ Known uses
—patterns found in real systems
▪ Related patterns
Adapter Pattern

▪ Problem:
▪ How to convert the interface of a class into another
interface the clients expect.
▪ Adapter lets classes work together that could not otherwise
because of incompatible interfaces.

▪ Real World Example: AC Power Adapters

▪ Electronic products made for Europe cannot be used
directly with outlets found in Egypt.
▪ To use, you need an AC power adapter.
Adapter Pattern

▪ Consider the following hierarchy . Another class is required

to be added for circles.
 Adapter Pattern
▪ Fortunately, there is a class called xxcircle ,from another library that deals
with circles already but we can’t use it directly, coz it has interface different
from the shape class interface (the names of XXCircle methods are different
from the names of the methods of the shape class) and we want to preserve
the polymorphic behavior with shape.

▪ We will develop a new class circle. Circle class derives from the shape class.
▪ Circle has the shape class interface and contains an object to XXCircle.
▪ Circle (adapter) passes requests made to circle object to XXCircle class
(adaptee).
Adapter Pattern

▪ Example:
Adapter Pattern
▪ Context:
—You are building an inheritance hierarchy and want to
incorporate an existing class into it.
—The reused class is also often already part of its own
inheritance hierarchy.
▪ Problem:
—How to obtain the power of polymorphism when reusing a
class whose methods:
- have the same function but not the same signature as the
other methods in the hierarchy?
—i.e. How to convert the interface of a class into another
interface the clients expect.
▪ Forces:
—You do not have access to multiple inheritance or you do not
want to use it.
Adapter Pattern
▪ Solution:
Rather than directly incorporating the reused class into
your inheritance hierarchy, instead incorporate an “Adapter”
class. Adapter class is connected by an association to the reused
class (Adaptee). The polymorphic methods of the Adapter class
delegate to the methods of the Adaptee class.
 Adapter Pattern

▪ The Adapter pattern converts the interface of a class into

another interface that clients expect. Adapter lets classes work
together that couldn’t otherwise because of incompatible
interfaces.

▪ The client makes a request on the Adapter by invoking a

method from the target interface on it. The Adapter translates
that request into one or more calls on the Adaptee using the
Adaptee interface The client receives the results of the call and
never knows that there is an Adapter doing the translation.
 Façade Pattern
▪ Context:
—Often, an application contains several complex packages/ subsystems.
—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?
- i.e. we need a way to interact with the system in an easier way than
the current one.
▪ Forces:
—It is hard for a programmer to understand and 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.
 Façade Pattern
▪ Solution: Create a special class called “Facade” which will simplify the use of
the package. The “Facade” will contain a simplified set of public methods such
that most other subsystems do not need to access the other classes in the
package. Consequently the package will be easier to use and has a reduced
number of dependencies with other packages. Any change in the package may
lead to redesign to the façade class not classes on other packages.
Facade Pattern

▪ Façade provide a unified interface to a set of interfaces in a

subsystem. Facade defines a higher-level interface that makes
the subsystem easier to use. I.e. it wraps a complex
subsystem with a simplified interface.

▪ Façade could be used not only as a simple interface but also

as a way to reduce the number of objects that a client object
must deal with to get certain service. For example:
▪ A home theater system :
—includes Amplifier , DVDplayer , projector , CD Player,
TheaterLights.
—Each with its own interface and interclass dependencies.
Facade Pattern

▪ Imagine steps for “watch movie”

▪ dim lights, screen down, projector on, set projector to DVD, amplifier
on, set amplifier to DVD, DVD on, etc.

▪ Now imagine resetting everything after the movie is done, or

configuring the system to play a CD, or play a video game,
etc.
▪ For this example, we can place high level methods like
“watch movie”, “reset system”, “play cd” in a facade object
and encode all of the steps for each high level service in the
façade.
Facade Pattern

▪ Façade simplifies the client code and reduce dependencies

—A facade not only simplifies an interface, it decouples a
client from a subsystem of components.

—Facade lets us encapsulate subsystems, hiding them

from the rest of the system.
Facade Pattern
▪ Example: the Facade pattern simplifies interaction with a
complex video conversion framework.

https://refactoring.guru/design-patterns/facade
Façade vs. Adaptor

▪ These two patterns appear to be similar. They both act as wrappers of

preexisting classes.

▪ They both take an interface that we don’t need and convert it to an

interface that we can use.
▪ With Facade, the intent is to simplify the existing interfaces.
▪ With Adapter, we have a target interface that we are converting to; we
often want the adapter to plug into an existing inheritance hierarchy
and behave polymorphically.

▪ Superficial difference Facade hides many classes; Adapter hides only one.
But adapter can wrap multiple objects at once in order to access all the
functionality it needs.

▪ So the difference between them is in the intent not in the implementation :

simplify (facade) vs convert (adapter)
Read-only Interface Pattern
▪ Context:
—You sometimes want certain privileged classes to be able to
modify attributes of objects that are otherwise immutable.

▪ Problem:
—How do you create a situation where some classes see a class as
read-only whereas others are able to make modifications?

▪ Forces:
—Restricting access by using the public, protected and private
keywords is not adequately selective.
—Making access public makes it public for both reading and
writing
 Read-only Interface
▪ Solution: Create a “Mutable” class as you would create any other
class. You pass instances of this class to methods that need to make
changes.
Then create a public interface “ReadOnlyInterface” , that has only the
read-only operations of “Mutable”. You associate the ReadOnly
interface “ to classes that don’t need to make changes to Mutable
attributes.
Read-only Interface anti-Patterns

1. Make the read-only class a subclass of the «Mutable» class,

and Override all the methods that modify the Mutable class
attributes
—such that they throw an exception

This doesn’t work as you want a single class with different sets
of access rights.
Abstraction-Occurrence Pattern
▪ Context:
▪ 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.
▪ Examples:
▪ All copies of the same book in a library, have the same
author name, #of pages, publisher; but each copy has a
different barcode number.
▪ Flights that leave at the same time for the same destination,
have the same flight number and airlines; but they leave at
different dates, with different passengers and crew.
Abstraction-Occurrence Pattern

▪ Problem:
▪ What is the best way to represent such sets of occurrences?

▪ Forces:
▪ You want to represent the members of each set of occurrences
without duplicating the common information.
 Abstraction-Occurrence Anti-Patterns
▪ Using single class, there will be an object for each book ,
—This solution leads to duplication of information in the
multiple copies of the book.
▪ Inheritance also will lead to the same result.
Abstraction-Occurrence Pattern

▪ Solution:
▪ Create an “abstraction” class that contains the common
data.
▪ Then create an “occurrence ” class representing the
occurrences of this abstraction.
▪ Connect these classes with a one-to-many association
Abstraction-Occurrence Pattern

▪ Example1:

▪ Example 2:
References

▪ Design Patterns: Elements of Reusable Object-Oriented Software,

Gamma, Helm, Johnson and Vlissides, addison-Wesley, 1995. (GOF)

▪ Head First Design Patterns, Freeman and Freeman, O'Reilly,2004.

▪ Design patterns explained, a new perspective on object oriented design,

Allan Shalloway, James Trott, Addison-Wesley, 2002.

▪ Design patterns for dummies, Steven Holzner.