Microsoft Word OpenIssuesInOO. doc

The export approach.The programmer must define which attributes are visible and which 

are hidden. This is the case in Simula , C++,  and Eiffel where mechanisms like hidden 

and protected (Simula), public, private, protected (C++), and export (Eiffel) are used 

for this purpose. 

The modularisation approach. A class definition is split into an interface part and an 

implementation part that often resides in different modules and/or files. This is the case 

for Modula 3 and BETA. 

---

In the ADT-approach, the interface only consists of operations whereas the export- and 

modularisation approach allow other attributes as well. The difference in approach is an 

open issue since there is no general consensus on which one is best. When programming 

general libraries and frameworks of classes, the public interface should be well defined and 

the internal details of a class should not be exposed. The ADT-approach seems to support 

this directly, but has no way of hiding private operations, and when instance variables are 

part of the public interface, extra interface operations will have to be invented. The export- 

and modularisation approaches can simulate the ADT-approach, but require convention and 

discipline.  In addition they make it possible to hide private operations and to define 

instance variables as part of the public interface.  

The advantage of the modularisation approach over the export approach is that the 

interface and the implementation are split into two or more modules or files. It is therefore 

possible to change the implementation parts of a class without changing the file containing 

the interface. In addition it is simple to implement a compiler where the implementation of a 

class can be changed and recompiled without having to recompile all clients of the class. 

Support for incremental compilation is an important practical issue for statically-typed 

languages. 

One reason for not choosing the ADT-approach, is that  in many modules there are a 

large number of local classes for which it is inconvenient to access objects via interface 

operations. When classes have local visibility only, accessing instance variables directly is 

harmless. 

When defining data models, the bottom layer of the database often consists of raw data 

to be represented by objects. These objects may be stored in an object-oriented data base. 

Another set of classes is often provided to access these data, such that change in the 

representation does not affect the user. When accessing the basic data, it is both 

inconvenient and unnecessary to do so via interface functions. 

Finally from a modeling perspective, it is desirable to describe a class and a set of 

objects in terms of classification and composition. In addition to describing the 

class/subclass relations, it is thus also necessary to be able to describe the composition 

structure in terms of  part objects/patterns and object/pattern references. Making part objects 

and references part of the public interface may be a dilemma with respect to encapsulation 

and uniform reference, since a change in the model  affects all usage's of the description. A 

uniform notation for accessing attributes may compensate for this, but such a notation may 

be difficult to obtain. 

It may also be the case that there is a need to implement the model in another way than it 

is described. This is easy when the interface/model is just a set of operations, but more 

difficult when part objects, and references are also part of the interface.  

In general there seem to be a conflict  between modeling and information hiding. For 

modeling one wants to describe the structure of a object in such a way that its elements 

represent aspects of the real world phenomenon. For information hiding one wants to hide 

as much of the structure of an object as possible.