Implementation

[Previous] [Next]

You can implement the Object Factory design pattern in Microsoft Visual Basic in various ways. Let's examine a few. First, adhering to the object model, you could design a Factory interface that defines a method for creating objects of a specific type. The Product interface in that diagram represents the type of object expected by the client. For each class that implements the Product interface, a corresponding class that implements the Factory interface is required. A parallel hierarchy of concrete factories and products must be maintained.

To lessen the number of factories, a hybrid of the functionality of the Factory and something else can be combined. For example, in the "Scenario" section, Figure 8-1 contains classes SybaseDB and AccessDB that implement the Database interface. As you might expect, the Database interface defines methods to open and close a database and a property for setting the login timeout threshold. (You can probably imagine other relevant database functionality that would be useful to define in this interface.) Notice, however, that in addition to this expected functionality the Database interface defines an OpenResultset method. This method is used to create concrete Resultset objects that correspond to the Database object implementation. The client uses this method to submit queries to the database that return results. It's only logical to have the Database implementation create and populate its associative Resultset object with the results from the database. As shown in Figure 8-1, there are three parallel class hiearchies: DBFactory, Database, and Resultset. Instead of having a fourth (RSFactory), the function of creating Resultset objects is consolidated with the function of retrieving the results from the database.

Combining the creation of related objects in one factory interface is yet another approach that not only lessens the number of factories required but also groups interdependent, compatible products. For example, to build an automobile you need an engine, a body, doors, windows, wheels, and so on. One can appreciate the fact that automobiles come in all shapes and sizes. Hence the components that make up a particular model are in most cases unique to that model. Moving the intelligence of identifying compatible components from the assembler (client) on the assembly line to the manufacturer (factory) in the department that is casting the parts in metal will make the process more efficient and dynamic. In more object-oriented terms, despite the fact that interfaces expected by the client remain static (you always need doors), the state and behavior of objects that implement these interfaces are dynamic (you need doors that fit) and can be the cause of incompatibilities that are enforceable only through intelligent processing (source code that validates implementation of an interface and the state of a given object).

Grouping the creation of compatible components under a single factory interface allows a concrete factory class instance to process intelligently by constructing and initializing objects with appropriate behavior and in a valid state relative to other components created by the factory. Figure 8-2 is a plausible representation of an Object Factory design pattern for the BSTAM automobile manufacturer. Depending on the StammerFactory, the assembler is either assembling a 576i or a 586i. The factory guarantees the assembler is working with compatible body and engine parts. True to the real specifications, both models share the same body but have different engines. To support the engine in the 586i, significant adjustments to the suspension are required. These adjustments are encapsulated in the body. Hence not only are the engines incompatible (which is obvious from looking at the diagram), but so are the bodies because the state of the body must be initialized to different values in order to reflect the required suspension adjustments (which is not obvious from looking at the diagram, but is handled by the appropriate StammerFactory.CreateBody method).

click to view at full size.

Figure 8-2. Object Factory design pattern that illustrates manufacturing of related components in a single factory, as a result guaranteeing compatibility between interdependent objects and lessening the number of concrete factories required.

Another variation of the Object Factory design pattern, shown in Figure 8-3, that will further limit the number of factories required involves designing a parameterized object factory. The create method of the factory accepts a parameter that allows it to create an instance of a particular class that supports the expected interface. Referring back to the BSTAM automobile example illustrated in Figure 8-2, you will notice there are separate instances of the StammerFactory object factory for manufacturing parts for distinct models (576i and 586i). Although this approach might seem to be the most sensible, these factories can be consolidated into one FiveSeriesFactory object factory. The create method for each component created must be passed a parameter that contains the model type (576i or 586i). This design variation might be the best option for BSTAM since they produce other model lines such as the 6, 7, and 8 series. The advantage of this approach is that it's easier to deploy new implementations, such as a 566i. A simple change and redeployment of the ActiveX DLL containing the FiveSeriesFactory class is all that is needed to add the new implementation. Also, because the object factory knows the list of supported parameters, you can provide a value-added feature to applications by including the ability to query the object factory for this list. Maybe this feature can appear in the form of menu options on a user interface, the number of which dynamically grows and shrinks depending on the currently registered ActiveX DLL.

click to view at full size.

Figure 8-3. Parameterized Object Factory that consolidates the number of factories used in Figures 8-1 and 8-2 by requiring a parameter to be passed to each create method.



Microsoft Visual Basic Design Patterns
Microsoft Visual Basic Design Patterns (Microsoft Professional Series)
ISBN: B00006L567
EAN: N/A
Year: 2000
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net