OO Idiom: Interfaces for derived classes

[mmann@ibm.net (Gerd Moellmann)]

Dear Ada users,

I am currently investigating Ada for OO programming, and I would like
to ask you for your comments wrt a question of programming style 

After studying the ARM and "Ada as a second language" (Normal
H. Cohen, 1996), I came to the conclusion that Ada as a language does
not directly address/ has no apparently obvious approach wrt

   whether it is desirable to separate interfaces for clients of
   classes vs. derived classes, and if so, how to implement the
   separation.

IMO, this question is of great interest in the construction of
reusable, stable components in OO systems (I made this experienced in
several large projects done in C++.) 

I strongly disagree with the idea of implementing derived classes in
child packages of the package containing the base class.  This allows
derived class implementations to access all private data and functions
of a base class (even up the base class chain).  Changing a base
class' private implementation therefore possibly breaks a potentially
large number of derived classes.  From my experience in C++ projects
this implementation is a BAD idea that should be avoided wherever
possible.  Derived classes should instead use interface functions of
their base class to implement their services.  Information hiding
principles should apply between base and derived classes as well as
between a class and its clients.

If we agree on this principle, there would be three possible
implementations of such a derived class interface:

  i)   in the package where the base class type is defined
  ii)  in a nested package thereof
  iii) in a child package thereof

Choice i) would make the derived class interface part of the public
interface advertised to all clients of a class.  This is, IMHO, also a
BAD idea wrt information hiding.  It would advertise services in the
public interface of a class that clients really are not allowed to
request.

Choice ii) has the same problem.  Services in a nested package would
require us to provide functions called by them in the outer package
which would then again become part of the public interface.

These were the reasons I got to the following coding idiom:

   o For every tagged type "base" in a package "base_package", the
   public interface of "base" is declared in "base_package" as
   normally for ADTs.

   o Functions and procedures needed for derived class implementation
   are declared in the private section of "base_class" when they must
   be primitive.  

   o A child package "base_class.derived" contains, in its public
   interface, functions/procedures that together form the interface of
   "base" for derived classes.  These functions may access private
   functions/ data of "base" because "base_package.derived" is
   considered to be part of class "base".

   o A derived class "derived" is implemented in a package
   "derived_package" that is not a child package of "base_package" to
   prevent "derived" from relying on the private implementation of
   "base". 

   o "derived" uses the public interface of "base" together with the
   services in "base_package.derived" for its implementation.

What are your thoughts about it?  Do you think it is as important as I
do?  Are there perhaps other ways of doing it?




-- 
Gerd Moellmann, Altenbergstr. 6, D-40235 Duesseldorf, Germany
Software Development & Consulting
Internet: mmann@ibm.net / CIS: 100025,3303 / Phone: +49 211 666 881