Professional Documents
Culture Documents
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
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
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.