Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
Consider a user interface toolkit that supports multiple look-and-feel standards, such as Motif and Presentation Manager. Different look-and-feels define different appearances and behaviors for user interface "widgets" like scroll bars, windows, and buttons. To be portable across look-and-feel standards, an application should not hard-code its widgets for a particular look and feel. Instantiating look-and-feel-specific classes of widgets throughout the application makes it hard to change the look and feel later.
We can solve this problem by defining an abstract WidgetFactory class that declares an interface for creating each basic kind of widget. There's also an abstract class for each kind of widget, and concrete subclasses implement widgets for specific look-and-feel standards. WidgetFactory's interface has an operation that returns a new widget object for each abstract widget class. Clients call these operations to obtain widget instances, but clients aren't aware of the concrete classes they're using. Thus clients stay independent of the prevailing look and feel.
There is a concrete subclass of WidgetFactory for each look-and-feel standard. Each subclass implements the operations to create the appropriate widget for the look and feel. For example, the CreateScrollBar operation on the MotifWidgetFactory instantiates and returns a Motif scroll bar, while the corresponding operation on the PMWidgetFactory returns a scroll bar for Presentation Manager. Clients create widgets solely through the WidgetFactory interface and have no knowledge of the classes that implement widgets for a particular look and feel. In other words, clients only have to commit to an interface defined by an abstract class, not a particular concrete class.
A WidgetFactory also enforces dependencies between the concrete widget classes. A Motif scroll bar should be used with a Motif button and a Motif text editor, and that constraint is enforced automatically as a consequence of using a MotifWidgetFactory.
The next step is to translate the domain definitions into a number of Elisa components.
The first domain definition is a selection domain. It specifies a number of alternative domains. The implementation of selection domains is based on the concepts of categories. The first component implements the WidgetFactory = MotifWidgetFactory | PMWidgetFactory.
The definitions in this component use patterns for dynamic type matching to select the definition rule which corresponds to the matching type. For example, the first definition rule of the Scrollbar definition test first if the type of the WidgetFactory argument is of the MotifWidgetFactory type. If that is the case, the corresponding Scrollbar function will be executed. Otherwise the following definition rule will be tried.
The second domain definition, MotifWidgetFactory = MotifScrollbar + MotifWindow, is easier. It specifies the interfaces to the MotifWidgetFactory. The actual implementation depends on the Motif look and feel functions.
The component of the third domain definition, PMWidgetFactory = PMScrollbar + PMWindow,is similar to the implementation of the second domain definition. It specifies the interfaces to the PMWidgetFactory. The actual implementation depends on the Presentation Manager look and feel functions.
The client as a user may now use a look-and-feel standard. He selects first a standard by calling either the CreateMotifWidgetFactory( ) or the CreatePMWidgetFactory( ). Both definitions will return an object of the specified type. Both object can also be converted to the WidgetFactory category. For example, suppose the client wants to use the Presentation Manager. He may use the following script:
This page was last modified on 13-11-2012 16:00:34