UNITIV

APPLICATION OF DESIGN PATTERNS

Design Patterns – C reational – factory method – Structural –
Bridge – Adapter – Behavioural –Strategy – observer -Applying GoF
design patterns – Mapping design to code. Applications: Satellite
Based Navigation-Traffic Management-Bank Management System-
Crypt Analysis- Weather Monitoring System.
Design Patterns
Software design patterns are essential tools for developers, providing
proven solutions to common problems encountered during software
development.

Design patterns are reusable solutions to common problems in software

design. They represent best practices used by experienced object-oriented
software developers. Design patterns provide a standard terminology and
are specific to particular scenarios.

Key Characteristics of Design Patterns

 Reusability: Patterns can be applied to different projects and problems,

saving time and effort in solving similar issues.

 Standardization: They provide a shared language and understanding

among developers, facilitating communication and collaboration.

 Efficiency: By using established patterns, developers can avoid reinventing

the wheel, leading to faster and more reliable development.
 Flexibility: Patterns are abstract solutions that can be adapted to fit various
contexts and requirements.
 Design Patterns
GoF patterns
 Design patterns provide solutions to common software design problems. In the case
of object-oriented programming, design patterns are generally aimed at solving the
problems of object generation and interaction, rather than the larger scale problems of
overall software architecture.

 Design patterns are a powerful tool for software developers. However, they should not
be seen as prescriptive specifications for software

 This section gives a high-level description of the twenty-three design patterns described
by the Gang of Four (1.Erich Gamma, 2. Richard Helm, 3.Ralph Johnson and 4. John
Vlissides)

 All the 23 patterns divided were into 3 groups namely 1.Creational Pattern, 2.Structural
and 3. Behavioral patterns

(1) Creational Patterns

Factory

Name: Factory

Problem: Who should be responsible for creating objects when there are
special considerations, such as complex creation logic, a desire to
separate the creation responsibilities for better cohesion, and so
forth?
Solution (advice): Create a Pure Fabrication object called a Factory that handles the creation.

Factory objects have several advantages:

Separate the responsibility of complex creation into cohesive helper objects.

Hide potentially complex creation logic.

Allow introduction of performance-enhancing memory management strategies, such

as object caching or recycling.
Example:

(2) Structural Patterns

1. Adapter: Match interfaces of different classes. Convert the interface of a class into
another interface clients expect. Adapter lets classes work together that couldn’t
otherwise because of incompatible interfaces.

2. Bridge: Separates an object’s interface from its implementation. Decouple an

abstraction from its implementation so that the two can vary independently.

ADAPTER

 An adapter helps two incompatible interfaces to work together.

 Adapter Pattern translates one interface for a class into a compatible interface.

 An adapter allows classes to work together that normally could not because of
incompatible interfaces

 Adapter pattern works as a bridge between two incompatible interfaces. This type of
design pattern comes under structural pattern as this pattern combines the capability of
two independent interfaces.
  This pattern involves a single class which is responsible to join functionalities of
independent or incompatible interfaces. A real life example could be a case of card
reader which acts as an adapter between memory card and a laptop. You plugins the
memory card into card reader and card reader into the laptop so that memory card can
be read via laptop.

 Convert (adapt) the interface of a class to interface expected by clients

 We've an interface MediaPlayer interface and a concrete class AudioPlayer
implementing the MediaPlayer interface. AudioPlayer can play mp3 format audio files
by default.

 We're having another interface AdvancedMediaPlayer and concrete classes

implementing the AdvancedMediaPlayerinterface.These classes can play vlc and mp4
format files.

Template

Name: Adapter
Problem: How to resolve incompatible interfaces, or provide a stable interface to similar
components with different interfaces?
Solution (advice): Convert the original interface of a component into another interface, through
an intermediate adapter object.
BRIDGE

The bridge pattern is a Gang of Four design pattern. This is a structural pattern as it defines a
manner for creating relationships between classes or entities.

The bridge pattern is a design pattern used in software engineering which is meant
to "decouple an abstraction from its implementation so that the two can vary independently.

The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities
into different classes.

 This pattern involves an interface which acts as a bridge which makes the functionality
of concrete classesindependent from interface implementer classes. Both types of
classes can be altered structurally without affecting each other.

 The bridge pattern is used to separate the abstract elements of a class from the
implementation details.

 For example, the abstract elements may be the business logic of an application. They
can be created without any knowledge of the implementation details of their data
access or interoperability with the operating system. The pattern provides the means to
replace the implementation details without modifying the abstraction. This permits, for
example, changing operating systems, databases, etc. with no impact to the business
logic.

 When the bridge pattern is not used, you may find that implementation details are
included within the same classes as abstract elements. The way in which
implementation details are changed is then generally be through inheritance, with
subclasses providing different implementations.
 Another benefit of the bridge pattern is that it introduces the possibility of changing the
implementation details at run-time. This could permit the user to switch
implementations to determine how the software interoperates with other systems. For
example, allowing the user to decide whether to store information in a database, XML
file or using another storage mechanism.
The UML class diagram above describes an implementation of the bridge design pattern. The
items in the diagram are described below:

Abstraction: This class contains members that define an abstract business object and its
functionality. It also acts as the base class for other, more refined, abstractions.

RefinedAbstraction: Many refined abstractions may inherit from the Abstraction class.
Each provides a more specific variation upon the abstraction but still contains no
implementation details other that those in the Implementation object reference that they
hold.

ImplementationBase: This abstract class is the base class for all classes that provide
implementation details for the associated abstractions. The class provides a fixed interface
that can be utilised by the abstractions. The interface need not be similar to that of the
abstraction. This class may be implemented as an interface if it provides no real
functionality for its subclasses.

ConcreteImplementation: The ConcreteImplementation class inherits form the

ImplementationBase class. There may be multiple concrete implementation classes, each
providing the same interface but providing platform-specific functionality.

 Example
  An interface DrawAPI interface which is acting as a bridge implementer and concret
classes RedCircle, GreenCircle implementing the DrawAPI interface. Shape is an
abstract class and will use object of DrawAPI. BridgePatternDemo, our demo class
will use Shapeclass to draw different colored circle.
Template:

Name: Bridge

Problem: We want to decouple an abstraction from its implementation?

Solution (advice): Decouple an abstraction from its implementation by 1, Delegate
implementation and 2. Inheritance

(3) Behavioral Patterns

Observer Pattern

 The observer pattern is a software design pattern in which an object, called the
subject, maintains a list of its dependents, called observers, and notifies them
automatically of any state changes, usually by calling one of their methods

 It is mainly used to implement distributed event handling systems

Define a one-to-many dependency between objects so that when one object changes state,
all its dependents are notified and updated automatically.
Example:

The Observer defines a one-to-many relationship so that when one object changes state,
the others are notified and updated automatically. Some auctions demonstrate this pattern.
Each bidder possesses a numbered paddle that is used to indicate a bid. The auctioneer
starts the bidding, and "observes" when a paddle is raised to accept the bid. The acceptance
of the bid changes the bid price which is broadcast to all of the bidders in the form of a new
bid.

Template:

Name: Observer (Publish-Subscribe)

Problem: Different kinds of subscriber objects are interested in the state
changes or events of a publisher object, and want to react in
their own unique way when the publisher generates an event.
Moreover, the publisher wants to maintain low coupling to the
subscribers. What to do?
Solution (advice): Define a "subscriber" or "listener" interface. Subscribers implement
this interface. The publisher can dynamically register subscribers who are interested in
an event and notify them when an event occurs.
Strategy

The strategy pattern (also known as the policy pattern) is a software design pattern that
enables an algorithm's behaviour to be selected at runtime.

The strategy pattern

 Defines a family of algorithms,
 Encapsulates each algorithm, and
 Makes the algorithms interchangeable within that family.

 Define a family of algorithms, encapsulate each one, and make them

interchangeable. Strategy lets the algorithm vary independently from the clients
that use it.

 Capture the abstraction in an interface; bury implementation details in derived

classes.

 The Strategy pattern encapsulates alternative algorithms (or strategies) for a

particular task. It allows a method to be swapped out at runtime by any other
method (strategy) without the client realizing it. Essentially, Strategy is a group
of algorithms that are interchangeable.
 Example:

Say we like to test the performance of different sorting algorithms to an array of

numbers: shell sort, heap sort, bubble sort, quicksort, etc. Applying the Strategy pattern
to these algorithms allows the test program to loop through all algorithms, simply by
changing them at runtime and test each of these against the array. For Strategy to work
all method signatures must be the same so that they can vary without the client
program knowing about it.

Template:

Name: Strategy
Problem: How to design for varying, but related, algorithms or policies? How
to design for the ability to change these algorithms or policies?
Solution (advice): Define each algorithm/policy/strategy in a separate class, with a
common interface.