AS3 Store Model: Encapsulation and Information Hiding
Back to Description of SBA and SBQL.
Back to Abstract Object Store Models
Back to AS0 Store Model
Back to AS1 Store Model
Back to AS2 Store Model
Encapsulation is a human civilization principle which essence is abstraction from details of some artifacts, wrapping details into some non-transparent capsules, and manipulation of complex artifacts as closed atomic units. For instance, looking on the car we have a lot of encapsulated parts, for instance, a gear-box. Similarly in electronics: a chip encapsulates millions of details. As for other technical branches, encapsulation is also the basic principle of software engineering. It is applied during software production to reduce the complexity of software manufacturing processes and to reduce the complexity of software products. The reducing of the complexities is based on top-down or bottom-up strategies. The top-down strategy assumes that software producers design or manufacture more abstract entities, and then, subsequently rectify their details. In the bottom-up strategy details are wrapped into a more abstract whole which hide the details are not seen and the whole is manipulated as a black-box, only by defined external properties.
Programming languages introduce several concepts that address the encapsulation principle. Among them we have software modules, procedures, functions, abstract data types and classes. For instance, a procedure may encapsulate a lot of code which is not interesting for the programmer who uses calls of the procedure. He/she is interested only in what the procedure is doing and how it has to be invoked. Also the database domain has contributed to encapsulation by such concepts as relational tables (encapsulating complex physical implementation), database views, triggers, and perhaps others. The middleware technologies such as CORBA, Web Services, RMI and EJB, Enterprise Service Bus, virtual repositories, etc. also can be perceived as contributions to the encapsulation principle.
In this section we are interesting in the particular case of encapsulation that concerns objects and classes. While we consider encapsulation as inevitable, the problem is how it can be introduced to an object-oriented database model. Note that some particular way of introducing the concept can be the subject of critics. For instance, C.J.Date in the text entitled Encapsulation is a Red Herring strongly argues against the concept, claiming that it leads to impossibility to define query languages. Date’s arguments are correct; fortunately they do not concern encapsulation as such, but some popular variant of encapsulation that we do not accept too.
Orthogonal v/s Orthodox Encapsulation
There are several ways how encapsulation can be involved into the concepts of a module, class, object and type. The most popular way is known from C++; a similar idea is accomplished in Modula-2. The idea can be referred to as orthogonal encapsulation. In short, a module, a class, an object or a type has some internal properties which are assigned as public or private. (C++ and its successors have additionally some intermediate qualifier known as protected.) The assignment is fully in hands of the designer or programmer: he/she can assign the flag public or private to any property, independently of its kind. For instance, the flag public can be assigned to an attribute within an object, i.e. the orthogonal encapsulation does not exclude that some part of the object state will be seen outside the object or its class. As a consequence, the orthogonal encapsulation assumes that such visible parts of the object state are to be served by special generic language constructs, such as a generic assignment operator, generic delete operator, etc., which act directly on references to some elements of the object state. Obviously this idea of encapsulation makes no problem for the definition of query languages, because all attributes of an object are directly accessible. For instance, this kind of encapsulation is implicitly assumed in ODMG OQL.
Some methodologists presenting object-oriented notions worked out another encapsulation concept, which we refer to as orthodox encapsulation. According to this idea, the state of an object should be totally hidden for the programmers. All what one can do with an object should be determined by methods associated with it. Generic operations on the object state, such as assignments, inserts or deletes, are disallowed. In particular, generic operations on an attribute, e.g. Sal, are substituted by two methods: so-called getter (getSal), which returns the value of the attribute, and so-called setter (setSal), which changes the value of the attribute according to a parameter.
However, we have doubts concerning such an idea. We agree with the Date’s arguments, but the inference is different. We accept encapsulation but not the orthodox encapsulation. Even the Date’s argument that the (orthodox) encapsulation is contradictory to query languages is invalid and concerns syntax rather than semantics. If we assume that each getter has the same name as the name of the attribute that it gets, then it will be possible to construct a query language in the spirit of SQL, where all the attribute names would be in fact invocations of getters. This is simply a syntactic convention which is not difficult to accomplish in any system. Hence it is possible to build a query language, despite the orthodox encapsulation.
Our arguments against the orthodox encapsulation are much stronger:
Summing up, our final conclusion is the following:
In our proposal we follow the orthogonal encapsulation, where each property of a module, class, object or type can be public or private, independently of its kind.
The AS3 Store Model
By default, if an export list is not defined for a particular class it means that all properties of the class and members of this class are public. Public properties are available externally according to regular scoping rules (that we introduce later). Private properties (not present on a corresponding export list) are available only within bodies of the methods that are stored within the corresponding class. We can easily introduce another privacy kind known as protected; we discuss this small issue later, when we present the semantics of classes and scoping rules for binding names.
Fig.13. Example of an AS3 object store extending an AS1 object store by export lists
The name ExportList is reserved for the internal use only. By this declaration we assume that all properties of PersonClass and Person objects are public. Concerning the EmpClass and Emp objects, properties named changeSal, netSal, worksIn are public, the property sal and other properties are private, hence available only in bodies of the methods changeSal and netSal. So far we present only situation in the object store. Detailed discussion concerning how export lists will be handled by the semantics of a query language will be presented later.
Last modified: December 31, 2007