Back Home Up Next

BUILDER

1 Purpose

2 Problem Description

3 Domain Definitions

4 Elisa Components

1 Purpose

 

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

 

2 Problem Description

A reader for the RTF (Rich Text Format) document exchange format should be able to convert RTF to many text formats. The reader might convert RTF documents into plain ASCII text or into a text widget that can be edited interactively. The problem, however, is that the number of possible conversions is open-ended. So it should be easy to add a new conversion without modifying the reader.

A solution is to configure the RTFReader class with a TextConverter object that converts RTF to another textual representation. As the RTFReader parses the RTF document, it uses the TextConverter to perform the conversion. Whenever the RTFReader recognizes an RTF token (either plain text or an RTF control word), it issues a request to the TextConverter to convert the token. TextConverter objects are responsible both for performing the data conversion and for representing the token in a particular format.

Subclasses of TextConverter specialize in different conversions and formats. For example, an ASCIIConverter ignores requests to convert anything except plain text. A TeXConverter, on the other hand, will implement operations for all requests in order to produce a TeX representation that captures all the stylistic information in the text. A TextWidgetConverter will produce a complex user interface object that lets the user see and edit the text.

Each kind of converter class takes the mechanism for creating and assembling a complex object and puts it behind an abstract interface. The converter is separate from the reader, which is responsible for parsing an RTF document.

The Builder pattern captures all these relationships. Each converter class is called a builder in the pattern, and the reader is called the director. Applied to this example, the Builder pattern separates the algorithm for interpreting a textual format (that is, the parser for RTF documents) from how a converted format gets created and represented. This lets us reuse the RTFReader's parsing algorithm to create different text representations from RTF documentsójust configure the RTFReader with different subclasses of TextConverter.

3 Domain Definitions

We will transform the RTFReader application into a set of corresponding Domain Definitions:

TextConverter = ASCIIConverter | TeXConverter | TextWidgetConverter

ASCIIConverter = Character + Text

TeXConverter = Character + Font + Paragraph + Text

TextWidgetConverter = Character + Font + Paragraph + Text

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 TextConverter = ASCIIConverter | TeXConverter | TextWidgetConverter.

component TextConverters;
type TextConverter = category(ASCIIConverter, TeXConverter, TextWidgetConverter);
     ConvertCharacter(TextConverter, char) -> optional(boolean);
     ConvertFontChange(TextConverter, Font) -> optional(boolean);
     ConvertParagraph(TextConverter, Para) -> optional(boolean);
     GetText(TextConverter) -> optional(Text);
begin
    ConvertCharacter(ASCIIConverter:Text, char)= ConvertCharacter(Text,char);
    ConvertCharacter(TeXConverter:Text, char) = ConvertCharacter(Text,char);
    ConvertCharacter(TextWidgetConverter:Text, char)= ConvertCharacter(Text,char);

    ConvertFontChange(TeXConverter:Text, Font)= ConvertFontChange(Text,Font);
    ConvertFontChange(TextWidgetConverter:Text, Font)= ConvertFontChange(Text,Font);

    ConvertParagraph(TeXConverter:Text, Para) = ConvertParagraph(Text, Para);
    ConvertParagraph(TextWidgetConverter:Text, Para) = ConvertParagraph(Text, Para);

    GetText(ASCIIConverter: text) = GetASCIIText(text);
    GetText(TeXConverter: text) = GetTeXTest(text);
    GetText(TextWidgetConverter: text) = GetTextWidget(text);

end component TextConverters;
 
 

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, ASCIIConverter = Character + Text, is simpler. It specifies the interfaces to the ASCIIConverter.  

 

component ASCIIConverters;
type ASCIIConverter;
     CreateASCIIConverter( ) -> ASCIIConverter;
     ConvertCharacter(ASCIIConverter, char) -> optional(boolean);
     GetASCIIText(ASCIIConverter) -> optional(Text);
begin
        << implementations of >>
     CreateASCIIConverter( ) = ...;
     ConvertCharacter(ASCIIConverter, char) = ...;
     GetASCIIText(ASCIIConverter) = ...;
end component ASCIIConverters;
         

 

The component of the third domain definition, TeXConverter = Character + Font + Paragraph + Text,is similar to the implementation of the second domain definition. It specifies the interfaces to the TeX conversion functions. The actual implementation depends on those TeX conversion functions.

 

component TeXConverters;
type TeXConverter;
     CreateTeXConverter( ) -> TeXConverter;
     ConvertCharacter(TeXConverter, char) -> optional(boolean);
     ConvertFontChange(TeXConverter, Font) -> optional(boolean);
     ConvertParagraph(TeXConverter, Para) -> optional(boolean);
     GetTeXText(TeXConverter) -> optional(Text);
begin
        << implementations of >>
     CreateASCIIConverter( ) = ...;
     ConvertCharacter(Converter, char) = ...;
     ConvertFontChange(Converter, Font) = ...;
     ConvertParagraph(Converter, Para) = ...;
     GetTeXtText(Converter) = ...;
end component TeXConverters;
         

 

The component of the fourth domain definition, TextWidgetConverter = Character + Font + Paragraph + Text,is similar to the implementation of the domain definition for TeXConverters.

 

 

Back Home Up Next            

  Part 5: Design Patterns   Builder

 
            
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 15:57:59   

free hit counter