0% found this document useful (0 votes)
9 views8 pages

UnderstandingDP Session 4

Uploaded by

Dev Panchal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views8 pages

UnderstandingDP Session 4

Uploaded by

Dev Panchal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Understanding

Design Patterns
The Observer Pattern
 Context
• When you create a two-way association between two classes, the code for the classes becomes
inseparable.
• When you compile one, the other one has to be available since the first one explicitly refers to it.
• This means that if you want to reuse one of the classes, you also have to reuse the other; similarly, if
you change one, you probably have to change the other.

 Problem
• How do you reduce the interconnection between classes, especially between classes that belong to
different modules or subsystems?
• In other words, how do you ensure that an object can communicate with other objects without
knowing which class they belong to?

 Forces
• You want to maximize the flexibility of the system to the greatest extent possible.
The Observer Pattern ...cont'd
 Solution
• Create an abstract class we will call the «Observable» that maintains a collection of
«Observer» instances.
• The «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.
This is illustrated in Figure on next slide.
• «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.
The Observer Pattern ...cont'd
 Example
• In order to obtain a weather forecast, a system has to perform a long sequence of
calculations.
• Suppose that these computations are under the control of a Forecaster object, as
shown in Figure.
• When a new forecast is ready this object notifies all interested instances. The
Forecaster is therefore the observable object.
• One observer might be a user interface object responsible for displaying the weather
forecast.
• Another observer might use weather forecasts to plan the schedule of some workers –
the workers might do one set of tasks on rainy days and another set on sunny days.
• The Observer pattern is widely used to structure software cleanly into relatively
independent modules.
The Observer Pattern ...cont'd
Note - It is also widely known as Publish-and-Subscribe (the observers are
Subscribers and the observable is a Publisher).
The Adapter Pattern
 Context
 You are building an inheritance hierarchy and you want to incorporate into it a class
written by somebody else – that is, you want to reuse an existing unrelated class.
 Typically
the methods of the reused class do not have the same name or argument types
as the methods in the hierarchy you are creating.
 The reused class is also often already part of its own inheritance hierarchy.
 Problem
 How do you obtain the power of polymorphism when reusing a class whose methods
have the same function but do not have the same signature as the other methods in the
hierarchy?
 Forces
 You do not have access to multiple inheritance or you do not want to use it.
The Adapter Pattern ...cont'd
 Solution
 Ratherthan directly incorporating the reused class into your inheritance hierarchy, instead
incorporate an «Adapter» class, as shown in Figure.
 The «Adapter» is connected by an association to the reused class, which we will call the «Adaptee».
 The polymorphic methods of the «Adapter» delegate to methods of the «Adaptee».
The delegate method in the «Adaptee» may or may not have the same name as the delegating polymorphic method.
 Other code that accesses facilities of an «Adapter» object will be unaware that it is indirectly using
the facilities of an instance of the «Adaptee».
 Example
 Imagine
you are creating a hierarchy of three-dimensional shapes. However, you want to reuse the
implementation of an equivalent class called TimsTorus.
 You do not want to modify the code of TimsTorus, since it is also being used by others; therefore
you cannot make TimsTorus a subclass of Shape3D. You therefore make Torus an «Adapter». Its
instances have a link to an instance of TimsTorus , and delegate all operations to TimsTorus.
The Adapter Pattern ...cont'd

You might also like