©Copyright by Kazimierz Subieta.

AS3 Store Model: Encapsulation and Information Hiding

by Kazimierz Subieta

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:

• It is not true that the object-orientedness implies this kind of encapsulation. The mission of object-orientedness is seamless mapping between real-life business objects and computer-side data structures (called objects) and v/v. All other assertions concerning object-orientedness are rhetoric froth that we do not buy if it is not based on strong pragmatic considerations concerning usability, consistency and efficiency of programming interfaces.
• It is not true that direct access to an object state is error prone. For more than 40 years computer folks developed hundreds of useful programming and query languages that assume the direct access to attributes (of records, tuples, structures, etc.). The folks have written billions lines of useful code under this assumption. It didn’t result in any catastrophic disadvantage. The problem is artificially invented in shallow rhetoric of some object-oriented gurus.
• The orthodox encapsulation violates the object relativism principle. For instance, the programmer is allowed to use an assignment to an attribute on the level of a method code, but he/she is disallowed to do that on the level of an entire object. But an attribute is an object too and the principle claims for no syntactic and semantic differences concerning objects on any object hierarchy levels.
• The orthodox encapsulation violates the principle of orthogonality of collection types. For instance, an object can contain a repeating attribute Hobbies with unknown number of repetitions. Obviously, in such a case two methods, getHobbies and setHobbies, are not enough. In such case the object-oriented gurus recommend to use iterators, i.e. methods such as getFirstHobby, getNextHobby, isNextHobby?, etc. There are severe problems with iterators concerning their state, see Iterators: Signs of Weakness in Object-Oriented Languages by Henry G. Baker. We put attention on another aspect. What would return a method such as getNextHobby? To achieve full universality (e.g. the possibility to remove a single hobby) the method should return a reference to this element of the object state. How such a reference has to be served by the language constructs? Again, the language designers should provide generic operations such as assignment and delete. Hence, we have received the contradiction: the orhodox encapsulation assumes that the object state is hidden, but iterators create a back door: they make a part of the state visible. The orthodox encapsulation assumes no generic operations on elements of the object state, but iterators make little sense without such operations.
• Similar arguments as the above can be repeated in case when an object can contain null values, optional data, complex attributes or variants: in all such cases a getter and a setter is not enough to serve all the cases.
• The orthodox encapsulation is inconsistent with the idea of a database schema, which is an inevitable pragmatic component of any database programming interface.
• The orthodox encapsulation is contradictory to query languages if one assumes that an object can be complex, with optional, repeating, variant and complex attributes, can be linked by pointer links, can contain dynamic roles, etc.
• The orthodox encapsulation introduces conceptual difficulties with generic programming. For instance, it is possible that objects of different classes contain an attribute of some type that has to be served (updated) by external routines. The most convenient method is to pass a reference to such an attribute to the routines in the call-by-reference mode. The orthodox encapsulation makes this impossible.

Summing up, our final conclusion is the following:

For object-oriented databases the orthodox encapsulation (in which the state of an object is totally hidden) is a conceptual nonsense.

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

In the AS3 model we augment a class of the AS1 or AS2 model with an export list containing the names of all public properties of the class and of the objects being the members of this class.

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.

S – Objects

< i₁, Person, {< i₂, name, ”Doe”>, ... } >,

< i₅, Emp, {< i₆, name, ”Poe”>, < i₇, sal, 2000>, < i₈, worksIn, i₂₂>, ... } >,

< i₉, Emp, {< i₁₀, name, ”Lee”>, < i₁₁, sal, 900>, < i₁₆, worksIn, i₃₃>, ...} >

C - Classes

< i₄₀, PersonClass, {< i₄₁, age, (...the code of the method age)>, ... other invariants of the PersonClass... } >,

< i₅₀, EmpClass, { < i₅₁, changeSal, (... the code of the method changeSal...)>,

< i₅₂, netSal, (... the code of the method netSal ...)>,

< i₅₃, ExportList, (changeSal, netSal, works_in) >,

... other invariants of the EmpClass... } >

R - Start identifiers

i₁, i₅, i₉

CC - Inheritance among classes

< i₅₀, i₄₀>

SC - Membership of objects within classes

< i₁, i₄₀>, < i₅, i₅₀>, < i₉, i₅₀>

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