Abstract Factory Pattern
The aim of the Abstract Factory pattern is to provide a way to obtain an appropriate concrete factory that can provide the specific type of product required by a client. The client need only be aware of the Abstract Factory type and obtains the concrete f
- PDF / 324,755 Bytes
- 7 Pages / 439.37 x 666.14 pts Page_size
- 22 Downloads / 182 Views
Abstract Factory Pattern
19.1
Introduction
The aim of the Abstract Factory pattern is to provide a way to obtain an appropriate concrete factory that can provide the specific type of product required by a client. The client need only be aware of the Abstract Factory type and obtains the concrete factory either by directly accessing it or by obtaining it from a Factory of Factories. Each concrete Factory provides an implementation of a product and this by using an appropriate Factory the client can obtain different implementations as required.
19.2
Pattern Classification
Gang of Four Creational Pattern
19.3
Intent
To provide a way of creating families of different products without needing to know the actual implementing types.
19.4
Context
There are a number of common scenarios in which you will find the Abstract Factory pattern occurring. It could be used to abstract the windowing system being used away from the client. In such a situation a abstract WidgetFactory might be extended by a OSXWidgetFactory and a WindowsWidgetFactory. Each providing a range of different products (such as Window, a Dialog, a Menu, Menu bar etc. but J. Hunt, Scala Design Patterns: Patterns for Practical Reuse and Design, DOI 10.1007/978-3-319-02192-8_19, © Springer International Publishing Switzerland 2013
155
156
19
Abstract Factory Pattern
implemented based on OSX or MS Windows technologies). The client merely needs to access the appropriate factory to obtain the appropriate version of the products required.
19.5
Forces/Motivation
The Abstract Factory Pattern can be used when • A client must be able to work with a set of products for which there are multiple different implementations and we wish to hide that detail from the client. • It should be possible to configure the set of products made available to the client based on some configuration information. • We wish to enforce consistency amongst the implementations of products created. • The different types of product should only be used with products associated with the same family (for example, OSX Dialogs should only be used with OSX Windows and menus etc.). • Clients (and other client code) should be unaware of the different implementations of Products. • We wish to be able to extend the range of implementations of a set of Products without having to alter clients.
19.6
Constituent Parts
There are a number of roles in the Abstract Factory Pattern: Abstract Factory Defines the abstract type that will be used to define the interface supplied by the factories to clients. Concrete Factory This role is played by one or more implementing types that provide the concrete realization of the operations defined in the Abstract Factory. These operations instantiate different version of the products in the associated product hierarchies. Factory of Factories (Factory Provider) This role is used to provide an object that can supply the appropriate type of Concrete Factory based on some criteria or configuration information. Product An abstraction that represents a type o
Data Loading...
