Gang of Four(GOF) patterns

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 for joining functionalities of independent or incompatible interfaces. A real life example could be a case of a card reader which acts as an adapter between the 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 have 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 vac 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 classes independent 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 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 utilized 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 from 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 implemented and concrete classes RedCircle, GreenCircle implementing the DrawAPI interface. The shape is an abstract class and will use object of DrawAPI. BridgePatternDemo, our demo class will use Shape class to draw the 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 behavior 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.