SAS Object-Oriented Programming Concepts

Classes

A class defines a set of data and the operations you can perform on that data. Subclasses are similar to the classes from which they are derived, but they may have different properties or additional behavior. In general, any operation that is valid for a class is also valid for each subclass of that class.

Relationships among SAS/AF Classes

SAS/AF software classes support three types of relationships:

inheritance
instantiation
uses.

Inheritance

Generally, the attributes, methods, events, event handlers, and interfaces that belong to a parent class are automatically inherited by any class that is created from it. One metaphor that is used to describe this relationship is that of the family. Classes that provide the foundation for other classes are called parent classes, and classes that are derived from parent classes are child classes. When more than one class is derived from the same parent class, these classes are related to each other as sibling classes. A descendent of a class has that class as a parent, either directly or indirectly through a series of parent-child relationships. In object-oriented theory, any subclass that is created from a parent class inherits all of the characteristics of the parent class that it is not specifically prohibited from inheriting. The chain of parent classes is called an ancestry.

Class Ancestry

[Class Ancestry]

Whenever you create a new class, that class inherits all of the properties (attributes, methods, events, event handlers, and interfaces) that belong to its parent class. For example, the Object class is the parent of all classes in SAS/AF software. The Frame and Widget classes are subclasses of the Object class, and they inherit all properties of the Object class. Similarly, every class you use in a frame-based application is a descendent of the Frame, Object, or Widget class, and thus inherits all the properties that belong to those classes.

Instantiation

In addition to the inheritance relationship, SAS/AF software classes have an instantiation or an "is a" relationship. For example, a frame is an instance of the Frame class; a radio box control is an instance of the Radio Box Control class; and a color list object is an instance of the Color List Model class.

All classes are instances of the Class class. The Class class is a metaclass. A metaclass collects information about other classes and enables you to operate on other classes. For more information about metaclasses, see Metaclasses.

Uses

For some classes, a "uses" relationship exists. With a uses relationship, not all of the functionality that a class needs is defined by one class. Instead, a class can use the operations defined by another class. This process is called delegation. In SAS/AF software classes, the "uses" relationship is defined in two ways: delegation and composition.

delegation

With delegation, a method is automatically forwarded to a designated object (or list of objects, in some predetermined order) when it is not recognized by the object that initially received the message to execute the method. Each class has an optional delegates list, which is a list of complex attribute names (or, for legacy classes, instance variable names) to which undefined method calls are redirected. The delegates list contains named values; each item name matches the name of a complex attribute. When you call a method on an instance of the class and the method is not found in the object's class nor in any ancestor class, the method call is tried on each complex attribute (or instance variable) named in the delegates list until one of the named objects implements the method or until the list is exhausted. The delegate objects may, in turn, delegate the method. If none of the named objects implements the method, then the parent class's delegates list, if it exists, is tried next, and so on. If no delegates implement the method, there is an error.

Delegation is allowed whenever you call a method using SEND or NOTIFY routines. However, delegation is not allowed when you use dot notation on an object of a specific class. In order to use dot notation and delegation together, you must use a reference to a generic object. For example, the following will work

DCL object foo;
foo.delegatedMethod();

but the following will not

DCL lib.cat.someclass.class foo;
foo.delegatedMethod();

composition

Objects can work together to form composite objects. Collectively, the component objects form a composite object. The relationship that exists between the components and the composite object is called composition. With composition, a class implements a method by explicitly invoking that method on one or more objects; the other objects typically are stored in complex attributes. For example, consider a composite widget that is composed of an input field and three list boxes. The input field and the list boxes are the components. Note that the components may not have any explicit relationship with each other (except for the passive relationship of all being members of the same composite).

In a composite object, methods can be forwarded to individual objects within the composite object.

Some of the composite objects in SAS/AF software include

Dual Selector Control (experimental)
Extended Input Field (legacy class)
Toolbar (legacy class)

Types of Classes

Some SAS/AF software classes are specific types of classes.

Abstract classes
Models and viewers
Metaclasses.

Abstract Classes

Abstract classes group attributes and methods that are common to several subclasses. These classes themselves cannot be instantiated; they simply provide functionality for their subclasses.

The Widget class in SAS/AF software is an example of an abstract class. Its purpose is to collect properties that all widget subclasses can inherit. The Widget class cannot be instantiated.

Models and Viewers

In SAS/AF software, components that are built on the SAS Component Object Model (SCOM) framework can be classified either as viewers that display data or as models that provide data. Although models and viewers are typically used together, they are nevertheless independent components. Their independence allows for customization, flexibility of design, and efficient programming.

Models are non-visual components that provide data. For example, a Data Set List model contains the properties for generating a list of SAS data sets (or tables), given a specific SAS library. Some models may be attached to multiple viewers.

Viewers are components that provide a visual representation of the data, but they have no knowledge of the actual data they are displaying. The displayed data depends on the state of the model that is connected to the viewer. A viewer can have only one model attached to it at a time.

It may be helpful to think of model/view components as client/server components. The viewer acts as the client and the model acts as the server.

Models that are built on the SCOM framework are enabled for model/view communication through their support of a specified interface (such as sashelp.classes.staticStringList.intrface). Likewise, all controls that display items in lists have also been enabled for model/view communication by requiring the use of the same interface.

For more information, see Interfaces, Implementing Model/View Communication, and the SAS/AF online Help.

Metaclasses

As previously mentioned, the Class class (sashelp.fsp.Class.class) and any subclasses you create from it are metaclasses. Metaclasses enable you to collect information about other classes and to operate on those classes.

Metaclasses enable you to make changes to the application at run time rather than only at build time. Examples of such changes include where a class's methods reside, the default values of class properties, and even the set of classes and their hierarchy.

Metaclasses also enable you to access information about parent classes, subclasses, and the methods and properties that are defined for a class. Specifically, through methods of the Class class, you can

retrieve information about an application, such as information about the application's structure, which classes are being used, and which legacy classes use particular instance variables. Each class has a super class that is accessed by the _getSuper method. Every class also maintains a list of subclasses that is accessed with the _getSubclassList and _getSubclasses methods.
list the instances of a class and process all of those instances in some way. Each class maintains a list of its instances. You can use _getInstanceList and _getInstances to process all the instances.
create objects and classes at run time with the _new method. Instances of the metaclass are other classes.

For more information about metaclasses, see the Class class in the SAS/AF online Help.

Top of Page