|
|
| Line 11: |
Line 11: |
| | | | |
| | ===Code Example=== | | ===Code Example=== |
| − |
| |
| − | public abstract class CPU {
| |
| − |
| |
| − | } //class CPU
| |
| − |
| |
| − |
| |
| − | The concrete widget classes are simply classes that implement the widget interfaces:
| |
| − |
| |
| − |
| |
| − | class EmberCPU extends CPU {
| |
| − |
| |
| − | } // class EmberCPU
| |
| − |
| |
| − |
| |
| − | Below is code for a concrete factory class that creates instances of classes to test ember architecture computers:
| |
| − |
| |
| − |
| |
| − | class EmberToolkit extends ArchitectureToolkit {
| |
| − | public CPU createCPU() {
| |
| − | return new EmberCPU();
| |
| − | } // createCPU()
| |
| − |
| |
| − | public MMU createMMU() {
| |
| − | return new EmberMMU();
| |
| − | } // createMMU()
| |
| − | ...
| |
| − | } // class EmberFactory
| |
| − |
| |
| − | Below is the code for the abstract factory class:
| |
| − |
| |
| − | public abstract class ArchitectureToolkit {
| |
| − | private static final EmberToolkit emberToolkit = new
| |
| − | EmberToolkit();
| |
| − | private static final EnginolaToolkit
| |
| − | enginolaToolkit
| |
| − | = new EnginolaToolkit();
| |
| − | ...
| |
| − |
| |
| − | /**
| |
| − | * Returns a concrete factory object that is an
| |
| − | instance of the
| |
| − | * concrete factory class appropriate for the given
| |
| − | architecture.
| |
| − | */
| |
| − | static final ArchitectureToolkit getFactory(int
| |
| − | architecture) {
| |
| − | switch (architecture) {
| |
| − | case ENGINOLA:
| |
| − | &nbs
| |
| − | p; return enginolaToolkit;
| |
| − |
| |
| − | case EMBER:
| |
| − | &nbs
| |
| − | p; return emberToolkit;
| |
| − | ...
| |
| − | } // switch
| |
| − | String errMsg =
| |
| − | Integer.toString(architecture);
| |
| − | throw new
| |
| − | IllegalArgumentException(errMsg);
| |
| − | } // getFactory()
| |
| − |
| |
| − | public abstract CPU createCPU() ;
| |
| − | public abstract MMU createMMU() ;
| |
| − | ...
| |
| − | } // AbstractFactory
| |
| − |
| |
| − | Client classes typically create concrete widget objects using code that looks something like this:
| |
| − | public class Client {
| |
| − | public void doIt () {
| |
| − | AbstractFactory af;
| |
| − | af =
| |
| − | AbstractFactory.getFactory(AbstractFactory.EMBER);
| |
| − | CPU cpu = af.createCPU();
| |
| − | ...
| |
| − | } // doIt
| |
| − | } // class Client
| |
| | | | |
| | ===Reference=== | | ===Reference=== |
Revision as of 19:27, 18 February 2007
Definition
A software design pattern, the Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software would create a concrete implementation of the abstract factory and then use the generic interfaces to create the concrete objects that are part of the theme. The client does not know (nor care) about 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 its general usage.
UML Diagram
Picture sourced:[1]
Code Example
Reference
http://en.wikipedia.org/wiki/Abstract_factory_pattern
http://www.dofactory.com/Patterns/PatternAbstract.aspx
