| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (5 out of 8)

Representing Classes and Instances

Your physical system consists of numerous occurrences of similar objects. For example, you might have these types of physical objects in these types of industries:

In the manufacturing industry, your physical plant might consist of numerous robots in an assembly line.
In the chemical industry, your plant might consist of numerous tanks and pumps.
In the telecommunications industry, your system might consist of various nodes and switches.
In the financial industry, your systems might be computers and networks.

Your application might also need to keep track of various types of conceptual objects, such as recipes, transactions, and signals, as well as abstract data types, such as lists and arrays.

To represent objects of a similar type, you create instances that are a "type of" a particular class. The individual instances of the class are "analogous to" the other instances of the class.

You represent "type of" relationships and "analogous to" relationships in G2 by:

Creating a class definition, which describes the common characteristics, behaviors, and icon representation of every member of the class
Specifying the direct superior classes, which are the classes from which your class inherits its definition, also called, parent classes
Representing the common characteristics of the class as attributes
Representing the common behaviors of the class as methods
Creating instances of the class, which inherit all the attributes and methods of the class
Describing how each instance differs from other instances by providing specific values for their attributes

For example, you might create a class definition for a robot, which describes the common characteristics of all robots as attributes of the class, such as arm span. You would then define the common behaviors of all robots as methods of the class, for example, "grasp," "turn," and "tilt." You specify how each robot differs from each other by providing specific values for the attribute of each instance, for example, arm span equals 12 feet or 10 feet. You cause the robot to perform an action by making a call to one of the methods of the class. You can also use methods to animate the icons that represent the physical systems.

The following figure illustrates the concepts of classes and instances for the ROBOT class. The robot class defines the common attribute of its instances, Arm-span, and the common methods of its instances, grasp and turn. Each instance has the same icon but different names and attribute values, and each has the same set of methods:

Creating a Class Definition

This section summarizes the major steps in creating a class definition.

To create and specify a class definition:

Choose KB Workspace > New Definition > class-definition > class-definition.

Note: The object, connection, and message menu choices and associated definitions exist for compatibility with older KBs. You should always create class definitions.
Specify the Name and Direct-superior-classes of the class definition to specify the built-in classes from which the class inherits its definition.
For information on inheriting from multiple direct superior classes, see Using Multiple Inheritance.
Specify the Class-specific-attributes of the class definition to specify its characteristics.
Choose KB Workspace > New Definition > procedure > method-declaration to create a method declaration for the method.
Choose KB Workspace > New Definition > procedure > method to create a method for the class that implements its behaviors.
Choose edit icon on the class definition to edit its icon representation.

For detailed information on creating class definitions, see the G2 Reference Manual.

Displaying the G2 Class Hierarchy

To see all the available classes from which user-defined classes can inherit their definition, view the G2 class hierarchy by using the Inspect facility. You can view the entire class hierarchy starting from the ITEM class, or you can view the class hierarchy of any subclass of item.

To view the entire G2 class hierarchy:

Use the Inspect facility to show on a workspace the class hierarchy of item.

Creating Instances of a Class

You can create instances of a class both interactively and programmatically.

To create an instance of a class:

Choose create instance from the class definition menu.

Use the create action, and, optionally, the make permanent action to create the instance programmatically.

For detailed information on instances, see the G2 Reference Manual.

Guidelines for Creating User-Defined Classes

G2 provides a library of built-in classes from which your classes can inherit their definitions. Ultimately, all user-defined classes inherit from one of the built-in G2 classes. In addition, user-defined classes can inherit from any existing user-defined class.

Subclass Built-in Data Structures

When your application requires one of the built-in G2 data structures such as a variable or array, you have the option of using the built-in class directly or creating a subclass. If your application requires the same type of data structure with the same specifications in numerous locations, it is often useful to subclass the built-in class. By creating subclasses of variables and parameters, you avoid having to initialize the attributes each time your application needs an instance of the variable or parameter.

The subclasses of the OBJECT class from which your user-defined classes can inherit include these categories of classes:

Variables and parameters
Lists and arrays
Errors
Network classes for communication with external systems
Connection posts and junctions

For example, you might create a subclass of an item-array that specifies a particular class of item, or you might create a subclass of a connection with a specific cross-section pattern.

As another example, your application might require a variable that allows communication with an external system through the G2 Gateway. To provide this capability, you would:

Subclass the built-in variable class that supports the correct data type, such as FLOAT-VARIABLE
Subclass the built-in network class that provides communications
Create a user-defined class that inherits from each of these subclasses, using multiple inheritance

For more information, see the references in this table:

For information on... See...
Variable and parameter data types
Variable and Parameter Class Hierarchy

Subclassing variables and parameters
Creating a Subclass of Variable or Parameter

List and array data types
List and Array Class Hierarchy

Subclassing lists and arrays
Creating a Subclass of List or Array

Subclass User-Defined Classes

Once you have created a user-defined class, you can begin to build a class hierarchy by creating new classes that inherit from existing user-defined classes. Typically, your class hierarchy consists of classes that ultimately inherit from the OBJECT or ITEM class.

For guidelines on how to create a class hierarchy, see Guidelines for Creating Class Hierarchies.

Subclass Built-in Definition Classes

You might want to create your own subclasses of the G2-WORKSPACE class to provide user-defined workspaces with different colors for different types of knowledge. You might also want to create subclasses of the RULE class to provide user-defined rules with different scan intervals, focal classes, or categories. By subclassing built-in definition classes, you can extend these definitions to provide a custom development environment.

Your user-defined classes can inherit from any subclass of the ITEM class to create a subclass of these categories of definition classes:

Workspaces
Statements such as rules, formulas, and functions
Procedures and methods
Definition classes such as class definition and relation definition
Messages and text
Displays such as trend charts, dials, meters, buttons, sliders, type-in boxes

The top of the G2 class hierarchy is the G2 ITEM class. Thus, all objects in G2 are considered items. For consistency with object-oriented terminology, we often refer to G2 items as objects. However, keep in mind that some G2 objects, such as class definitions, methods, procedures, rules, and workspaces, are actually subclasses of the ITEM class and are considered items in G2.

Note: If you create a subclass that inherits only from the ITEM class, the resulting class will be non-instantiable.

Hide Private and Non-Instantiable Classes

G2 allows you to create instances of user-defined classes directly from the KB Workspace > New Object menu. In general, you should declare private and abstract classes to be non-instantiable, and you should keep them off the New Object menu. If your module provides a palette for the creation of new items, you should also remove from the New Object menu those classes that appear on the palette.

To declare a class as non-instantiable:

Specify the Instantiate attribute in the class definition as no.

To remove a class from the New Object menu:

Specify the Include-in-menus attribute in the class definition as no.

Use Message as the Superior Class for Non-Iconic Classes

If an item you define does not need a pictorial icon, you should consider using the MESSAGE class as the superior class. Aside from the ability of a message to contain text, the two reasons to inherit from message are:

When you display an instance of a class for the first time, the memory for its bitmap is automatically allocated in the client process. A large item, or an item shown at large scale, causes large bitmaps to be allocated. For example, a 1000 x 1000 pixel icon requires 1 MB. Messages do not have any similar memory penalty.
Objects have a upper limit on their icon size (1000 x 1000), whereas messages do not. Thus, you can use the icon representation of a message to create a large, opaque, rectangular area, which you might use for some other purpose than a message, such as a background area.

Programmatically, you can do almost anything with a message that you can do with an object, except rotate it and give it default stubs, although you can make connections programmatically.

| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (5 out of 8)

Copyright © 1997 Gensym Corporation, Inc.