Home

 

Getting Started with Elisa

Using EDS

Demo's

Tutorials

 

Language Description

1. Lexical Elements
2. Basic Data Types and Expressions
3. Definitions
4. Streams
5. Backtracking
6. Statements and Special Expressions
7. Arrays
8. Lists
9. Descriptors
10. Components
11. Collections
12. Generic Components
13. Terms
14. Categories
15. Types 

16. Built-in Definitions
17. Higher-order Definitions

18. External Interfaces

Index

Data Structures

1. Sequences
2. Examples involving Lists
3. Trees
4. Graphs
5. Searching State Spaces
6. Language Processing
7. Knowledge Representations          

 

Metaprogramming

1. Introduction
2. What are Domain Definitions?

3.  Sorts of Domain Definitions

4.  Manipulations of Domain Definitions

5.  Translating Domain Definitions

6.  Dialogue Sessions

7.  Example of Concentric Circles

8.  Example of Domain Substitution applied to Concentric Circles

9.  Example of an Order Processing Application

10.Example of an Airport Information System

11.Example of a Rental Boat Business

12.Benefits of Domain Definitions

   

Back Home Up Next


COMMAND

1 Purpose

2 Problem Description

3 Domain Definitions

4 Elisa Components

1  Purpose

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. Also known as Action or  Transaction

2  Problem Description

Sometimes it's necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request. For example, user interface toolkits include objects like buttons and menus that carry out a request in response to user input. But the toolkit can't implement the request explicitly in the button or menu, because only applications that use the toolkit know what should be done on which object. As toolkit designers we have no way of knowing the receiver of the request or the operations that will carry it out.

The Command pattern lets toolkit objects make requests of unspecified application objects by turning the request itself into an object. This object can be stored and passed around like other objects. The key to this pattern is an abstract Command class, which declares an interface for executing operations. In the simplest form this interface includes an abstract Execute operation. Concrete Command subclasses specify a receiver-action pair by storing the receiver as an instance variable and by implementing Execute to invoke the request. The receiver has the knowledge required to carry out the request.

Menus can be implemented easily with Command objects. Each choice in a Menu is an instance of a MenuItem class. An Application class creates these menus and their menu items along with the rest of the user interface. The Application class also keeps track of Document objects that a user has opened.

The application configures each MenuItem with an instance of a concrete Command subclass. When the user selects a MenuItem, the MenuItem calls Execute on its command, and Execute carries out the operation. MenuItems don't know which subclass of Command they use. Command subclasses store the receiver of the request and invoke one or more operations on the receiver.

For example, PasteCommand supports pasting text from the clipboard into a Document. PasteCommand's receiver is the Document object it is supplied upon instantiation. The Execute operation invokes Paste on the receiving Document.

OpenCommand's Execute operation is different: it prompts the user for a document name, creates a corresponding Document object, adds the document to the receiving application, and opens the document.

 

Sometimes a MenuItem needs to execute a sequence of commands. For example, a MenuItem for centering a page at normal size could be constructed from a CenterDocumentCommand object and a NormalSizeCommand object. Because it's common to string commands together in this way, we can define a MacroCommand class to allow a MenuItem to execute an open-ended number of commands. MacroCommand is a concrete Command subclass that simply executes a sequence of Commands. MacroCommand has no explicit receiver, because the commands it sequences define their own receiver.

In each of these examples, notice how the Command pattern decouples the object that invokes the operation from the one having the knowledge to perform it. This gives us a lot of flexibility in designing our user interface. An application can provide both a menu and a push button interface to a feature just by making the menu and the push button share an instance of the same concrete Command subclass. We can replace commands dynamically, which would be useful for implementing context-sensitive menus. We can also support command scripting by composing commands into larger ones. All of this is possible because the object that issues a request only needs to know how to issue it; it doesn't need to know how the request will be carried out.

3  Domain Definitions

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

Command = OpenCommand | PasteCommand | MacroCommand

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  Command domain.

component Commands;
type Command = category(
OpenCommand,PasteCommand,MacroCommand);

     Execute(Command) -> nothing;

       . . .
begin

            <<implementations of >>

     Execute(OpenCommand: openCommand)   = Execute(openCommand);

     Execute(PasteCommand: pasteCommand) = Execute(pasteCommand);

     Execute(MacroCommand: macroCommand) = Execute(macroCommand);

                           . . .

end component Commands;

 

 

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

 

component OpenCommands;
type OpenCommand;

     CreateOpenCommand(Application)  -> OpenCommand;
     Execute(OpenCommand) -> nothing;

     AskUser(OpenCommand) -> text; 

       . . .
begin

            <<implementations of >>
     CreateOpenCommand(application) = OpenCommand:[ ... application...];
     Execute(openCommand) = ...;

     AskUser(openCommand) = ...; 

        . . .

end component OpenCommands;

 

 

The following component is a skeleton example of a PasteCommand

 

component PasteCommands;
type PasteCommand;

     CreatePasteCommand(Document)  -> PasteCommand;
     Execute(PasteCommand)  -> nothing;

       . . .
begin

            <<implementations of >>
     CreatePasteCommand(document) = PasteCommand:[ ... document...];
     Execute(pasteCommand) = ...;

        . . .

end component PasteCommands;

 

 

The following component is a skeleton example of a MacroCommand

 

component MacroCommands;
type MacroCommand;

     CreateMacroCommand(Document )  -> MacroCommand;
     Execute(MacroCommand)  -> nothing;

       . . .
begin

            <<implementations of >>
     CreateMacroCommand() = MacroCommand:[ clist = alist(Command); ...];
     Execute(MacroCommand) = Execute(items(clist));

        . . .

end component MacroCommands;

 

Back Home Up Next

  Part 5: Design Patterns   Command

            
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

This page was last modified on 27-11-2012 16:56:26   

free hit counter