Structural Patterns

• Address issues concerned with the way in

which classes and objects are organized.
• Offers effective ways of using object-
oriented constructs such as inheritance,
composition and aggregation to satisfy
particular requirements.
       
Structural Patterns
• Adapter
• Bridge
• Decorator
• Façade
• Flyweight
• Proxy
• Composite
Adapter Pattern
• Consider a situation where there is a 3 and ½
inch floppy disk and a 5 and ½ inch drive.
• The disk cannot fit into the drive.
• The task:Cater to the client disk without
changing either the disk or the drive.
• Thus in order to make these two incompatible
interfaces work together, the interface of the
drive must be converted to an interface that the
disk expects.
• The Adapter pattern concept is used to make
two unrelated interfaces work together.
Adapter Pattern
• In our example, we make the drive output some
contents that are copied on to the disk.
• The Drive is declared to be an interface with one
method send_output() that tries to send output
to the disk.
• Since both are incompatible, the Adapter class
acts as an intermediary.
• It has a reference to the disk and it also
implements the Drive interface.
• It gives the output of the drive to the disk in a
manner that the disk understands.
 Adapter Pattern
• We use the adapter design pattern where the requirements is to convert
between one interface to another. Adapter pattern is never implemented
when designing a new system but with the changing requirements we have
deferring interfaces then adapter comes into picture.

•
 Adapter Pattern
• Example
We have used some library where we have Add function which takes
two integer and provides the sum of them. Now when upgrading the
libray we find that the library has changed the Add function such that
it takes 2 floating point number. Now one option could be to change
all the client code where we have used the Add method or other option
is to have an Adapter.

•
Bridge Pattern
• It decouples an abstraction from its
implementation so both can vary independently.
• E.g. Establishing the mileage of cars on
highways and city roads.
• The MarutiCar class is the base class.
• Maruti800 class extends MarutiCar class
• There is a class Road with a method
display_Mileage().
• The classes Highway and cityRoad extend the
Road class and implements the
display_Mileage() operation in their own
manner.
Bridge Pattern
• In Bridge pattern parlance, MarutiCar is the
abstraction, the Maruti800 class is the refined
abstraction, the Road is the implementer,
Highway and CityRoad are the concrete
implementers.
• The abstraction and the implementation are not
coupled with each other.
• A new type of car say MarutiZen could be added
as another refined abstraction or a new type of
Road say Suburban could be added as another
concrete implementer of the existing refined
abstraction.
Decorator Pattern
• It is used to add extra behaviour to specific
objects.
• E.g.A small construction firm initially sold flats
and shops.
• Later the firm had a drop in sales of upper floor
flats so they decided to rent them.
• To simulate this scenario, there is a class
ConstructionProject that has an attribute area
and a display method to display information
about the shop or flat.
• Two classes i.e. Flat and Shop inherit from
ConstrctionProject. Flat has the attributes flatId,
floorNo, noOfBedrooms and presenceOfBalcony.
• Shop has its own attributes i.e. shopId and own.
Decorator Pattern
• The problem before us is how to make the Flat
class leasable?
• Use a Decorator class that will have a
constructor to initialize the type of library item
to be decorated with extra behaviour.
• The actual decorator i.e. Leaseable class will
extend from the Decorator class, use its
constructor and will have a method leaseFlat()
to decorate the Flat class.
• If the shop has to be decorated then another
class can extend from the Decorator class and
add the appropriate behaviour.
 Facade Pattern
• In the case of large programs, a large number of
classes/subsystems can crop up with the result that it becomes
difficult to ascertain the flow of the program.
• There can be many subsystems, each with its own complicated
interface.
• It is convenient to have a single class that serves as an
intermediary between the client program and the
classes/subsystems.
• This intermediary will provide a simplified interface to all these
classes/subsystems.
• This intermediary is the façade that hides the complexity of the
structure from the client program.
Facade Pattern
• E.g. Problem is to select a cricket player based on his
performance in the matches of the previous season.
• The performance is rated on the basis of 3 factors i.e. the
runs scored, the wickets taken and the boundaries saved
during fielding.
• The data about runs, wickets and saved boundaries is
retrieved from the subsystems namely RunsScored,
WicketsTaken and BoundariesSaved.
• Player class that stores the personal information of the
players.So instead of the client program checking data of
players by dealing with each of the subsystems separately,
there is a façade class i.e. PlayerSelection that does this
task and provides an answer whether a particular player
can be selected or not.
Flyweight Pattern
• It is useful if there are a small number of
objects that are needed a large number of
times.
• Instead of creating the all the objects all the
time, certain objects can be reused wherever
possible.
• E.g.Problem of constructing 10 rectangles filled
with various colours.
• The created objects are stored in a HashMap.
• The task: Check whether a DrawRectangle
object of a certain area has already been
created. If it has been created then it is
retrieved from the HashMap and used else a
new object is instantiated.
Flyweight Pattern
• The RectangleFactory class whose job is to
manufacture DrawRectangle objects achieves
this task.
• In the example, the code is deliberately written
in such a manner that out of 10 rectangles half
of them have the same area but different
colours.
• So in reality only 5 DrawRectangle objects are
created and each of them is used twice.
• This problem must be seen in the perspective of
saving memory space if a thousand objects need
to be built and only half of them are actually
constructed and reused.
Proxy Pattern
• It is a pattern that separates the interface from the
implementation.
• The proxy object controls access to the real object.
• There are three classes called Client, RealSubject and Proxy
and one interface called Subject.
• The client always operates on the interface "Subject".
• The actual operations in the interface are implemented by
RealSubject class.
• They are also "implemented" by the "Proxy" class in the
sense that the Proxy forwards any calls it receives to the
RealSubject class.
• So, through the interface, the client class will work against
a Proxy object and so the Proxy will control access to the
RealSubject object.
Proxy Pattern
• E.g. There are 30 computers in a lab and only a computer to
which a printer is attached.
• Only persons with administrative privileges can take printouts. S
• uppose a user wants to take a printout and so he invokes the
print function.
• A Proxy object can first evaluate whether the user has
administrative privileges.
• If he doesn’t have the necessary privileges then he should be
disallowed.
• If he has the necessary privileges, then the Proxy can delegate
the job to the actual Printer.
• So, in this case, the RealSubject is the Printer.
• While checking the authorization, the Proxy can itself
communicate with some authorization object to decide whether
the access is allowed or not.
Proxy Pattern
• A Proxy can be used to enhance performance
and increase efficiency.
• Suppose if RealSubject object is too expensive
to create because it has to be fetched from
some other system.
• So a system can instantiate a cheap Proxy.
• When an operation is called in the Proxy, it will
confirm whether the RealSubject object is
instantiated or not.
• If it has been instantiated, then the request is
forwarded to it.
• Else it is instantiated by the Proxy and then the
requests is passed on to it.
Composite Pattern
• It is primarily used to indicate whole-part relationships and
let the client program treat both whole object and part
objects in the same manner.
• E.g. Finding the cost to a private college of an Employee.
• It is calculated as the sum of the cost(salary) of the
Employee and all Employees under him.
• In the college, the highest authority is the principal.
• He has 2 employees i.e. Vice principal of the Arts section
and the Vice Principal of the Science section.
• The Vice Principal of the Arts section has the Heads of
various departments(Philosophy, Sociology and Logic)
under him.
• The Vice Principal of the Science section has the Heads
Physics, Chemistry and Biology under him.
Composite Pattern
• Cost incurred by the college in employing the
Principal is the sum total of the salaries of the
Principal, the Vice Principals and the Heads of
various departments.
• Whereas, the cost incurred by the private
college in employing the head of Logic
department is the head’s own salary.
• The point is to have a single method to
calculate the cost of an employee to the college
irrespective of whether the employee is
primitive (does not have anybody under him) or
composite.
Composite Pattern
• In the implementation, the class
Employee has a designation, salary and
an ArrayList to record details about
employees working under him.
• It also has getSalaries() method which is
implemented in such a manner so as to
work for both types of objects whether
composite or primitive.