Back Home Up Next


1 Purpose

2 Problem Description

3 Domain Definitions

4 Elisa Components

1  Purpose

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Also known as Policy.

2  Problem Description

Many algorithms exist for breaking a stream of text into lines. Hard-wiring all such algorithms into the classes that require them isn't desirable for several reasons:

Clients that need linebreaking get more complex if they include the linebreaking code. That makes clients bigger and harder to maintain, especially if they support multiple linebreaking algorithms. 
Different algorithms will be appropriate at different times. We don't want to support multiple linebreaking algorithms if we don't use them all. 
It's difficult to add new algorithms and vary existing ones when linebreaking is an integral part of a client.

We can avoid these problems by defining classes that encapsulate different linebreaking algorithms. An algorithm that's encapsulated in this way is called a strategy.

Suppose a Composition class is responsible for maintaining and updating the linebreaks of text displayed in a text viewer. Linebreaking strategies aren't implemented by the class Composition. Instead, they are implemented separately by subclasses of the abstract Compositor class. Compositor subclasses implement different strategies:

SimpleCompositor implements a simple strategy that determines linebreaks one at a time. 
TeXCompositor implements the TeX algorithm for finding linebreaks. This strategy tries to optimize linebreaks globally, that is, one paragraph at a time. 
ArrayCompositor implements a strategy that selects breaks so that each row has a fixed number of items. It's useful for breaking a collection of icons into rows, for example.

A Composition maintains a reference to a Compositor object. Whenever a Composition reformats its text, it forwards this responsibility to its Compositor object. The client of Composition specifies which Compositor should be used by installing the Compositor it desires into the Composition.

3  Domain Definitions

We will transform the top-level relations into a set of corresponding domain definitions:

Compositor  =  SimpleCompositor | TeXCompositor  |  ArrayCompositor 

Composition  =  . . . +  . . .

The next step is to translate the domain definitions into a number of Elisa components. In addition, we will use skeletons of definitions as shown in the preceding domain relationships

4  Elisa components 

Based on the domain definitions a set of related components are derived. The first component implements  a skeleton of the  Compositor = Simple Compositor | TeXCompositor  |  Array Compositor  domain.

component Compositors;
type Compositor = category(Simple Compositor,TeXCompositor,ArrayCompositor);

     Compose(Compositor) -> result;

      . . .

            <<implementations of >>

     Compose(SimpleCompositor:simpleCompositor) = Compose(simpleCompositor);

     Compose(TeXCompositor:teXCompositor)       = Compose(teXCompositor);

     Compose(ArrayCompositor:arrayCompositor)   = Compose(arrayCompositor);

          . . .

end component Compositors;



The following component is a skeleton example of a SimpleCompositor component:


component SimpleCompositors;
type SimpleCompositor;

     CreateSimpleCompositor(Compositor) -> SimpleCompositor;

     Compositor(SimpleCompositor)       -> Compositor;

     Compose(SimpleCompositor)          -> result;

      . . .

            <<implementations of >>

     CreateSimpleCompositor(compositor) = SimpleCompositor:[ ..compositor... ];

     Compositor(simpleCompositor) = simpleCompositor.compositor;

     Compose(simpleCompositor) = ...;

          . . .

end component SimpleCompositors;



The following component is a skeleton example of a TeXCompositor


component TeXCompositors;
type TeXCompositor;

     CreateTeXCompositor(Compositor) -> TeXCompositor;

     Compositor(TeXCompositor)       -> Compositor;

     Compose(TeXCompositor)          -> result;

      . . .

            <<implementations of >>

     CreateTeXCompositor(compositor ) = TeXCompositor:[ ..compositor... ];

     Compositor(teXCompositor) = teXCompositor.compositor;

     Compose(teXCompositor) = ...;

          . . .

end component TeXCompositors;




The following component is a skeleton example of a ArrayCompositor


component ArrayCompositors;
type ArrayCompositor;

     CreateArrayCompositor(Compositor) -> ArrayCompositor;

     Compositor(ArrayCompositor)       -> Compositor;

     Compose(ArrayCompositor)          -> result;

      . . .

            <<implementations of >>

     CreateArrayCompositor(compositor ) = ArrayCompositor:[ ..compositor... ];

     Compositor(arrayCompositor) = arrayCompositor.compositor;

     Compose(arrayCompositor) = ...;

          . . .

end component ArrayCompositors;




The following component is a skeleton example of a Composition


component Compositions;
type Composition;

     CreateComposition(Compositor) -> Composition;

     Compositor(Composition) -> Compositor;

     Traverse(Composition)   -> result;

     Repair(Composition)     -> result;

      . . .

            <<implementations of >>

     CreateComposition(compositor ) = Composition:[ ..compositor... ];

     Compositor(composition) = composition.compositor;

     Traverse(composition) = . . .;

     Repair(composition) = . . .;

          . . .

end component Compositions;




Back Home Up Next

  Part 5: Design Patterns   Strategy


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 04-12-2012 14:47:38   

free hit counter