Higher level structure

In a first approximation we might define only Put and Get functions on the data store objects. A more refined study shows that we want operations like Window, Copy, Byte, Merge, Pad. By defining some higher-level operations on many of the objects, we move most of the problems into the objects that are, by the same strategy, made more reusable. A question remains. How do we arrange these objects with the best kind of interconnection? The simplest is to have a traditional hierarchical structure. We can create a superobject called Data which will encapsulate the objects Cube, Plane and Trace and associated operations. This Data superobject corresponds to coherent options of the Cube, Plane or Trace objects.

The use of high level objects yields the same advantages as low-level objects: encapsulation and isolation of related data and operations, enhanced mapping between the user's view of the system, potential reusability of subsystems, and increased control of complexity. Methods given to the Data Object are the operations cited in the previous paragraph (Window, ...). These functions can be applied to Data objects (Plane, ...). without making any assumption on the type of object. The behavior and the implementation becomes then very similar to the seplib programs where, from the user's point of view, no consideration on the data type is made when using a program.