Abstract factory design pattern

Abstract
The abstract factory pattern is a software creational design pattern that provides a way to
encapsulate a group of individual factories that have a common theme without specifying their
concrete classes.[1] In normal usage, the client software creates a concrete implementation of the
abstract factory and then uses the generic interfaces to create the concrete objects that are part of
the theme. The client does not know which concrete objects it gets from each of these internal
factories, since it uses only the generic interfaces of their products. This pattern separates the
details of implementation of a set of objects from their general usage and relies on object
composition, as object creation is implemented in methods exposed in the factory interface.
An example of this would be an abstract factory class

Builder Design pattern

Abstract
The builder pattern is a Gang of Four design pattern. This is a creational pattern as it is to
control class instantiation. The builder pattern is used to create complex objects with constituent
parts that must be created in the same order or using a specific algorithm. An external class,
known as the director, controls the construction algorithm.
An example of this pattern could exist in a

Facade Design pattern

Abstract
The facade pattern (or faade pattern) is a software design pattern commonly used with
object-oriented programming. The name is by analogy to an architectural facade. Facade pattern
can be used in JEE applications for creating a layer to abstract and unify the related interfaces in
the application. Use of a facade will define an entry point to each subsystem level and thus make
them communicate only through their facades; this can simplify the dependencies between
them.Faade makes the API and libraries easier to use which is good for maintenance and
readability. It can also collate and abstract various poorly designed APIs with a single simplified
API. It also reduces dependencies of the external code on the inner working of the libraries and
thus providing flexibility

Bridge Design pattern

Abstract
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 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 abstraction. In this case, the way in which implementation details are changed is probably
through inheritance, with subclasses providing different implementations. This can be problematic

when refined abstractions are included, also through inheritance. The number of required classes can
grow exponentially as new abstractions and implementations are added to a system. In this model,
when there is a single implementation for a single abstraction, only one class is required whereas the
bridge pattern would involve three classes. However, if there were four abstractions and five
implementations, this would potentially require twenty classes versus the ten needed when using the
bridge pattern. This is due to the pattern removing platform dependencies from the abstraction
.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

Decorator Design pattern

Abstract
This pattern is designed so that multiple decorators can be stacked on top of each other, each
time adding a new functionality to the overridden method(s).The decoration features, maybe methods,
properties, or other members, usually defined by an interface or class inheritance, that is shared by
the decorators & the decorated object. In the previous example the class "Component" is inherited by
both the "ConcreteComponent" & the subclasses that descend from "Decorator".The decorator pattern
is an alternative to subclassing. Subclassing adds behavior at compile time, and the change affects all
instances of the original class; decorating can provide new behavior at run-time for individual
objects.This difference becomes most important when there are several independent ways of
extending functionality.
In some object-oriented programming languages, classes cannot be created at runtime, and it
is typically not possible to predict, at design time, what combinations of extensions will be needed.
This would mean that a new class would have to be made for every possible combination. By contrast,
decorators are objects, created at runtime, and can be combined on a per-use basis. The I/O Streams
implementations of both Java and the .NET Framework incorporate the decorator pattern.

Chain of Responsibility
Abstract
In writing an application of any kind, it often happens that the event generated by one object
needs to be handled by another one. And, to make our work even harder, we also happen to be denied
access to the object which needs to handle the event.
In this case there are two possibilities: there is the beginner/lazy approach of making
everything public, creating reference to every object and continuing from there and then there is the
expert approach of using the Chain of Responsibility.
The Chain of Responsibility design pattern allows an object to send a command without
knowing what object will receive and handle it. The request is sent from one object to another making
them parts of a chain and each object in this chain can handle the command, pass it on or do both. The
most usual example of a machine using the Chain of Responsibility is the vending machine coin slot:
rather than having a slot for each type of coin, the machine has only one slot for all of them. The
dropped coin is routed to the appropriate storage place that is determined by the receiver of the
command.
It avoids attaching the sender of a request to its receiver, giving this way other objects the possibility
of handling the request too.
The objects become parts of a chain and the request is sent from one object to another across the
chain until one of the objects will handle it.