Abstract Factory (GoF) for Families of Related Objects - UML

The JavaPOS implementations will be purchased from manufacturers. For example:

// IBM's drivers
com.ibm.pos.jpos.CashDrawer (implements jpos.CashDrawer)
com.ibm.pos.jpos.CoinDispenser (implements jpos.CoinDispenser)
// NCR's drivers
com.ncr.posdrivers.CashDrawer (implements jpos.CashDrawer)
com.ncr.posdrivers.CoinDispenser (implements jpos.CoinDispenser)

Now, how to design the NextGen POS application to use the IBM Java drivers if IBM hardware is used, NCR drivers if appropriate, and so forth?

Note that there are families of classes (CashDrawer + CoinDispenser+...) that need to be created, and each family implements the same interfaces.

Figure illustrates the basic idea; it is improved upon in the next section.

Figure 36.15 A basic abstract factory

A common variation on Abstract Factory is to create an abstract class factory that is accessed using the Singleton pattern, reads from a system property to decide which of its subclass factories to create, and then returns the appropriate subclass instance. This is used, for example, in the Java libraries with the java.awt.Toolkit class, which is an abstract class abstract factory for creating families of GUI widgets for different operating system and GUI subsystems.

The advantage of this approach is that it solves this problem: How does the application know which abstract factory to use? IBMJavaPOSDevicesFactory?
NCRJavaPOSDevicesFactory?

The following refinement solves this problem. Figure illustrates the solution.

With this abstract class factory and Singleton pattern getlnstance method, objects can collaborate with the abstract superclass, and obtain a reference to one of its subclass instances. For example, consider the statement:

cashDrawer = JavaPOSDevicesFactory.getlnstance().getNewCashDrawer();

The expression JavaPOSDevicesFactory.getlnstanceQ will return an instance of
IBMJavaPOSDevicesFactory or NCRJavaPOSDevicesFactory, depending on the system property that is read in. Notice that by changing the external system property "jposfactory.classname" (which is the class name as a String) in a properties file, the NextGen system will use a different family of JavaPOS drivers. Protected Variations with respect to a changing factory has been achieved with a data - driven (reading a properties file) and reflective programming design, using the c.newInstanceQ expression.

Interaction with the factory will occur in a Register. By the goal of low representational gap, it is reasonable for the software Register (whose name is suggestive of the overall POS terminal) to hold a reference to devices such as CashDrawer. For example:

class Register
{
privatejpos.CashDrawercashDrawer;
privatejpos.CoinDispensercoinDispenser;
public Register() {
cashDrawer = JavaPOSDevicesFactory.getlnstance().getNewCashDrawer();

Figure 36.16 An abstract class abstract factory


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics