Back Home Up Next

ABSTRACT FACTORY

1 Purpose

2 Problem Description

3 Domain Definitions

4 Elisa Components

1 Purpose

 

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

 

 

2 Problem Description

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.

3 Domain Definitions

We will transform the Abstract Factory as illustrated by the WidgetFactory into a set of Domain Definitions:

WidgetFactory = MotifWidgetFactory | PMWidgetFactory 

MotifWidgetFactory = MotifScrollbar + MotifWindow 

PMWidgetFactory = PMScrollbar + PMWindow  

The next step is to translate the domain definitions into a number of Elisa components.

4 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. 

component WidgetFactories;

type WidgetFactory = category(MotifWidgetFactory, PMWidgetFactory);

type Scrollbar;

type Window;

     CreateScrollbar(WidgetFactory) -> optional(Scrollbar);

     CreateWindow(WidgetFactory)    -> optional(Window);

begin

    CreateScrollbar(MotifWidgetFactory: MWScrollbar) = CreateScrollbar(MWScrollbar);

    CreateScrollbar(PMWidgetFactory: PWScrollbar)    = CreateScrollbar(PWScrollbar);

 

    CreateWindow(MotifWidgetFactory: MWWindow) = CreateWindow(MWWindow);

    CreateWindow(PMWidgetFactory: PWWindow)    = CreateWindow(PWWindow);

end component WidgetFactories;

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.

 

component MotifWidgetFactories;

type MotifWidgetFactory;

     CreateMotifWidgetFactory( )   -> MotifWidgetFactory;

     CreateScrollbar(MotifWidgetFactory) -> Scrollbar;

     CreateWindow(MotifWidgetFactory)    -> Window;

begin

            << implementations of >>

    CreateMotifWidgetFactory( ) =  ... ;

    CreateScrollbar(MotifWidgetFactory) =  ... ;

    CreateWindow(MotifWidgetFactory)     =  ... ;

end component MotifWidgetFactories;

 

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.

 

component PMWidgetFactories;

type PMWidgetFactory;

     CreatePMWidgetFactory( )    -> PMWidgetFactory;

     CreateScrollbar(PMWidgetFactory ) -> Scrollbar;

     CreateWindow(PMWidgetFactory )    -> Window;

begin

            << implementations of >>

     CreatePMWidgetFactory( )   =  ... ;

     CreateScrollbar(PMWidgetFactory) =  ... ;

     CreateWindow(PMWidgetFactory)    =  ... ;

end component PMWidgetFactories;

 

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:

PresentationManager = CreatePMWidgetFactory( );

ALF = WidgetFactory: PresentationManager;    << ALF = Abstract Look and Feel >>

W = CreateWindow(ALF);

S = CreateScrollbar(ALF);

 

Back Home Up Next            

  Part 5: Design Patterns   Abstract Factory

            
Introduction

Home | Highlights of Elisa | Integrating Different Paradigms | Getting Started with Elisa | Demo's  | What is Domain Orientation | Bibliography | Copyright | News | Contact | Contents

Language Description:

Lexical Elements | Basic Data Types and Expressions | Definitions | Streams | Backtracking | Statements and Special Expressions | Arrays | Lists | Descriptors | Components | Collections | Generic Components | Terms | Categories | Types | Built-in Definitions | Higher-order Definitions | External Interfaces | Index 

Data Structures: Sequences | Examples involving Lists | Trees | Graphs | Searching State Spaces | Language Processing | Knowledge Representations
Domain Modeling:

Domain Modeling | Concepts | Domain Definitions | Domain Operations | Domain Implementations | Systems | Case study: an Order processing system | Case study: an Airport Support system | Domain Orientation versus Object Orientation

Design Patterns:

Introduction | Abstract Factory | Builder | Factory Method | Prototype | Singleton | Adapter | Bridge | Composite | Decorator | Facade | Flyweight | Proxy | Chain of Responsibility | Command | Interpreter | Iterator | Mediator | Memento | Observer | State | Strategy | Template Method | Visitor 

 

click tracking

 

Send me your comments

 

This page was last modified on 13-11-2012 16:00:34   

free hit counter