Back Home Up Next

FACTORY METHOD

1 Purpose

2 Problem Description

3 Domain Definitions

4 Elisa Components

1 Purpose

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

2 Problem Description

Frameworks use abstract classes to define and maintain relationships between objects. A framework is often responsible for creating these objects as well.

Consider a framework for applications that can present multiple documents to the user. Two key abstractions in this framework are the classes Application and Document. Both classes are abstract, and clients have to subclass them to realize their application-specific implementations. To create a drawing application, for example, we define the classes DrawingApplication and DrawingDocument. The Application class is responsible for managing Documents and will create them as required—when the user selects Open or New from a menu, for example.

Because the particular Document subclass to instantiate is application-specific, the Application class can't predict the subclass of Document to instantiate—the Application class only knows when a new document should be created, not what kind of Document to create. This creates a dilemma: The framework must instantiate classes, but it only knows about abstract classes, which it cannot instantiate.

The Factory Method pattern offers a solution. It encapsulates the knowledge of which Document subclass to create and moves this knowledge out of the framework.

Application subclasses redefine an abstract CreateDocument operation on Application to return the appropriate Document subclass. Once an Application subclass is instantiated, it can then instantiate application-specific Documents without knowing their class. We call CreateDocument a factory method because it's responsible for "manufacturing" an object.

3 Domain Definitions

We will transform the document application into a set of corresponding domain definitions:

 Application = MyApplication1 | MyApplication2 | . . . 

 Document = MyDocument1 | MyDocument2 | . . .

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

4 Elisa components

Based on the domain definitions a set of related components can be derived.

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 following component implements the Application = MyApplication1 | MyApplication2.

component Applications;
type Application = category(MyApplication1,MyApplication2);
     CreateDocument(Application) -> optional(Application);
     NewDocument(Application)    -> optional(Application);
     OpenDocument(Application)   -> optional(Application);
begin
     CreateDocument(MyApplication1:App) = CreateDocument(App);
     CreateDocument(MyApplication2:App) = CreateDocument(App);

     NewDocument(MyApplication1:App) = NewDocument(App);
     NewDocument(MyApplication2:App) = NewDocument(App);

     OpenDocument(MyApplication1:App) = OpenDocument(App);
     OpenDocument(MyApplication2:App) = OpenDocument(App);
end component Applications;

The definitions in this component use  patterns for dynamic type matching to select the definition rule which corresponds to the matching type. 

The following component illustrates one of MyApplications:

component MyApplications1;
type MyApplication1;
     CreateMyApplication1()         -> MyApplication1; 
     CreateDocument(MyApplication1) -> MyDocument1;
     NewDocument(MyApplication1)    -> MyDocument1;
     OpenDocument(MyApplication1)   -> MyDocument1;
begin
        << implementations of >>
     CreateMyApplication1( ) = ... 
     CreateDocument(App) = ... CreateMyDocument1(App) ...
     NewDocument(App)    = ... CreateMyDocument(App) ...
     OpenDocument(App)   = ... OpenDocument(App)...
end component MyApplications1;

The following component implements the Document = MyDocument1 | MyDocument2.

component Documents;
type Document = category(MyDocument1,MyDocument2);
     Open(Document) -> optional(Document);
     Close(Document) -> optional(Document);
     Save(Document) -> optional(Document);
     Revert(Document) -> optional(Document);
begin
     Open(MyDocument1:Doc) = Open(Doc);
     Open(MyDocument2:Doc) = Open(Doc);

     Close(MyDocument1:Doc) = Close(Doc);
     Close(MyDocument2:Doc) = Close(Doc);

     Save(MyDocument1:Doc) = Save(Doc);
     Save(MyDocument2:Doc) = Save(Doc);

     Revert(MyDocument1:Doc) = Revert(Doc);
     Revert(MyDocument2:Doc) = Revert(Doc);
end component Documents;    

The following component is an example of a MyDocument component:

 

component MyDocuments1;
type MyDocument1;
     CreateMyDocument1(MyApplication1) -> MyDocument1;
     Open(MyDocument1)   -> MyDocument1;
     Close(MyDocument1)  -> nothing;
     Save(MyDocument1)   -> nothing;
     Revert(MyDocument1) -> MyDocument1;
begin
          << implementations of: >>
     CreateMyDocument1(App) = ...;
     Open(Doc) = . . .;
     Close(Doc) = . . .;
     Save(Doc) = . . .;
     Revert(Doc) = . . .;
end component MyDocuments1;
    

Back Home Up Next

  Part 5: Design Patterns   Factory Method

 
            
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:07:54   

free hit counter