OO Idiom: Interfaces for derived classes

OO Idiom: Interfaces for derived classes

[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

Re: OO Idiom: Interfaces for derived classes

[Norman H. Cohen]

In article <mmannohpq347p.fsf@ibm.net>, mmann@ibm.net (Gerd Moellmann) writes: 

|> After studying the ARM and "Ada as a second language" (Normal
                                                               ^
This is an abnorman way to spell my name, but that's okay.  I've been
called worse things than "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.
...
|> 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
                         ^^^^^^^^^^ (Presumably you mean base_package.)
|>    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?

Note that your solution still requires voluntary compliance with a
convention--that only units implementing derived classes should contain
with clauses for base_package.derived.

Rather than trusting the whole rest of the program, I prefer the
"traditional" solution of declaring descendents of base_class in child
packages of base_package, which is more straightforward and only requires
trusting the writers of those child packages to use declarations in the
private part of base_package appropriately.

(If you are not the trusting sort, you can use an access-management
tool to ensure that no "unauthorized" children of base_package are
written.  After all, you must trust programmers not to make unauthorized
changes to the text of base_package itself, or else enforce this with an
access-management tool.  Page 471 of _Ada_as_a_Second_Language_ states,
"In a sense, since a child unit is logically nested inside its parent,
the author of a child package creates a modified version of the parent
package.  Only a programmer who would be trusted to modify the text of
the parent itself should be trusted to write a child unit of a package
with a private part.")

The situation gets more complicated when we turn our attention from a
snapshot, or release, of a program to a program as an living entity that
evolves over time, or to the distribution as a reusable component of a
package providing some OO class.  Then it becomes important for the
writer of the parent package to provide documentation distinguishing
those aspects of the parent package that represent supported parts of its
interface from those parts of the parent package that represent
implementation choices that may change in future releases of the parent
package.  At one extreme, the writer of the parent might guarantee the
proper functioning of the package only as long as no children are written
for it.  At the opposite extreme, the writer of the parent may commit to
preserving all the declarations in the private part of the package in all
future releases.  But the child should ask not (just) what the parent can
do for it; the child should ask too what it can do for (or to) its
parent:  If the writer of the parent does not rule out child packages
entirely, he must also document those invariants that all children of the
package must preserve if the package is to continue to function
correctly.

Back to the idiom you propose:  The usual reason for a derived class
referring directly to members of a base class is efficiency.  If you are
going to force all manipulations of the base-class implementation to be
through subprograms exported by Base_Package.Derived anyway, you lose the
motivation for giving implementations of derived classes special
privileges.  Why distinguish then between operations that are acceptable
only for derived classes to perform and those that are acceptable for all
clients to perform?  If you have truly hidden the implementation of the
base class from derived classes, then it would seem that any operation
deemed safe for the implementation of the derived class to perform will
also be safe enough for the world at large to perform.  If you have a
specific example that suggests otherwise, it would be interesting to see it.

Having said all that, if you really want to, there IS a way in Ada 95 to
mimic the C++ distinction between protected and private members, at the
cost of a level of indirection when accessing private members: 

   package P is
      type T is tagged private;
      ...
   private
      type Private_Components_Type;
      type Private_Components_Pointer_Type is access Private_Components_Type;
      type T is tagged
         record
            ...  -- "protected" components declared here
            Private_Components : Private_Components_Pointer_Type;
         end record;
   end P;

   package body P is
      type Private_Components_Type is
         record
            ... -- "private" components declared here
         end record;
      ...
   end P;

The "protected" components are visible in the private parts and bodies of
children of P, but the "private" components are not.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: OO Idiom: Interfaces for derived classes

[Gerd Moellmann]

ncohen@watson.ibm.com (Norman H. Cohen) writes:

> |> After studying the ARM and "Ada as a second language" (Normal
>                                                                ^
> This is an abnorman way to spell my name, but that's okay.  I've been
> called worse things than "normal". ;-)

:-))

> Note that your solution still requires voluntary compliance with a
> convention--that only units implementing derived classes should contain
> with clauses for base_package.derived.

Yes, the proposal requires voluntary compliance (which can be easily
checked if necessary) and it requires programmers to take an explicit
action---with'ing base_package.derived---to gain access to base class
internals. 

> Rather than trusting the whole rest of the program, I prefer the
> "traditional" solution of declaring descendents of base_class in child
> packages of base_package, which is more straightforward and only requires
> trusting the writers of those child packages to use declarations in the
> private part of base_package appropriately.

If we talk about "trusting" (I am not concerned about programmers
cluttering up something intentionally; I am primarily aiming at
getting a less coupled implementation with my proposal):

Don't class libraries, frameworks/patterns often require users to
derive classes from library classes?  Can it always be foreseen from
which classes it might be desirable to derive new classes?  The
"trusting scheme" would have to trust quite a lot of people, IMO.

> (If you are not the trusting sort, you can use an access-management
> tool to ensure that no "unauthorized" children of base_package are
> written.  After all, you must trust programmers not to make unauthorized
> changes to the text of base_package itself, or else enforce this with an
> access-management tool.  Page 471 of _Ada_as_a_Second_Language_ states,
> "In a sense, since a child unit is logically nested inside its parent,
> the author of a child package creates a modified version of the parent
> package.  Only a programmer who would be trusted to modify the text of
> the parent itself should be trusted to write a child unit of a package
> with a private part.")

I agree that this is true when derived classes are implemented in
child packages.  But I must add that it sounds like placing a burden
on programmers to me. I think of an application programmer using, say,
one class library for the user interface, another for database access,
and yet another one for communications.  If I had the choice to
either protect her against inadvertantly relying on non-public
features of one of maybe several hundred classes or trust her, I would
prefer the first alternative.

> The situation gets more complicated when we turn our attention from a
> snapshot, or release, of a program to a program as an living entity that
> evolves over time, or to the distribution as a reusable component of a
> package providing some OO class.  Then it becomes important for the
> writer of the parent package to provide documentation distinguishing
> those aspects of the parent package that represent supported parts of its
> interface from those parts of the parent package that represent
> implementation choices that may change in future releases of the parent
> package.  At one extreme, the writer of the parent might guarantee the
> proper functioning of the package only as long as no children are written
> for it.  At the opposite extreme, the writer of the parent may commit to
> preserving all the declarations in the private part of the package in all
> future releases.  But the child should ask not (just) what the parent can
> do for it; the child should ask too what it can do for (or to) its
> parent:  If the writer of the parent does not rule out child packages
> entirely, he must also document those invariants that all children of the
> package must preserve if the package is to continue to function
> correctly.

Agreed. This is true no matter how you implement derived classes.

> Back to the idiom you propose:  The usual reason for a derived class
> referring directly to members of a base class is efficiency. 

You can gain efficiency in my scheme by inlining subprograms.

> If you are
> going to force all manipulations of the base-class implementation to be
> through subprograms exported by Base_Package.Derived anyway, you lose the
> motivation for giving implementations of derived classes special
> privileges. Why distinguish then between operations that are acceptable
> only for derived classes to perform and those that are acceptable for all
> clients to perform?  If you have truly hidden the implementation of the
> base class from derived classes, then it would seem that any operation
> deemed safe for the implementation of the derived class to perform will
> also be safe enough for the world at large to perform.  If you have a
> specific example that suggests otherwise, it would be interesting to
> see it.

To cite [Rumbaugh, Object Oriented Modeling & Design, 1991 (p.322)],
(hope I got the name right:-), and this the intention behind my proposal:

"Encapsulation can be violated through careless use of inheritance. A
subclass inherits the attributes of its superclass, but if the methods
of the subclass directly access superclass attributes, the
encapsulation of the superclass is defeated.  CLOS, Owl, Eiffel and
C++ permit a class to restrict the visibility from its subclasses.
There are arguments in favor of allowing a class to access its
superclass, but the cost is tight binding between the classes.

Often it is useful to write some "private" operations that are for
internal use only by other methods of the same class. It is desirable
to restrict the visibility of these operations so that other classes
cannot use them.  It is often necessary to allow subclasses to access
these internal operations, so a simple distinction between public and
private is not possible..."

This meets exactly my experience in early C++ projects. Classes end up
tightly coupled.  Modifications/extensions become harder and harder
over time.  I believe this lesson was learned in C++---I didn't see
many C++ class libraries (maybe none?) in the last years.

> Having said all that, if you really want to, there IS a way in Ada 95 to
> mimic the C++ distinction between protected and private members, at the
> cost of a level of indirection when accessing private members: 
> 
>    package P is
>       type T is tagged private;
>       ...
>    private
>       type Private_Components_Type;
>       type Private_Components_Pointer_Type is access Private_Components_Type;
>       type T is tagged
>          record
>             ...  -- "protected" components declared here
>             Private_Components : Private_Components_Pointer_Type;
>          end record;
>    end P;
> 
>    package body P is
>       type Private_Components_Type is
>          record
>             ... -- "private" components declared here
>          end record;
>       ...
>    end P;
> 
> The "protected" components are visible in the private parts and bodies of
> children of P, but the "private" components are not.
> 

Yes, this letter-envelope pattern is usefull in its own right. As you
said, its costs can be high because the base class itself can only
access the private part with an additional indirection.

Thank you for your answer, Norman.  Although it didn't convince me to
drop my proposal it was interesting to hear your opinions.  May I add
a congratulation for your really fine book "Ada as a 2nd language"?
-- 
Gerd Moellmann, Altenbergstr. 6, D-40235 Duesseldorf, Germany
Software Development & Consulting
Internet: mmann@ibm.net / CIS: 100025,3303 / Phone: +49 211 666 881

Re: OO Idiom: Interfaces for derived classes

[Norman H. Cohen]

In article <mmannvijxa4ta.fsf@ibm.net>, mmann@ibm.net (Gerd Moellmann) writes: 

|> Yes, the proposal requires voluntary compliance (which can be easily
|> checked if necessary) and it requires programmers to take an explicit
|> action---with'ing base_package.derived---to gain access to base class
|> internals.
...
|> If we talk about "trusting" (I am not concerned about programmers
|> cluttering up something intentionally; I am primarily aiming at
|> getting a less coupled implementation with my proposal): 
|>
|> Don't class libraries, frameworks/patterns often require users to
|> derive classes from library classes?  Can it always be foreseen from
|> which classes it might be desirable to derive new classes?  The
|> "trusting scheme" would have to trust quite a lot of people, IMO.
...
|>                       I think of an application programmer using, say,
|> one class library for the user interface, another for database access,
|> and yet another one for communications.  If I had the choice to
|> either protect her against inadvertantly relying on non-public
|> features of one of maybe several hundred classes or trust her, I would
|> prefer the first alternative.

Okay, I see the value of your scheme as a way of making explicit those
features of the parent package that are part of the documented interface
for descendents.  Adherence to this interface can be easily enforced by a
combination of fine-grained compiler checks and coarse-grained checks
about program structure in the large by another tool.

I wrote: 

|> > The situation gets more complicated when we turn our attention from a
|> > snapshot, or release, of a program to a program as an living entity that
|> > evolves over time, or to the distribution as a reusable component of a
|> > package providing some OO class.  Then it becomes important for the
|> > writer of the parent package to provide documentation distinguishing
|> > those aspects of the parent package that represent supported parts of its
|> > interface from those parts of the parent package that represent
|> > implementation choices that may change in future releases of the parent
|> > package.  At one extreme, the writer of the parent might guarantee the
|> > proper functioning of the package only as long as no children are written
|> > for it.  At the opposite extreme, the writer of the parent may commit to
|> > preserving all the declarations in the private part of the package in all
|> > future releases.  But the child should ask not (just) what the parent can
|> > do for it; the child should ask too what it can do for (or to) its
|> > parent:  If the writer of the parent does not rule out child packages
|> > entirely, he must also document those invariants that all children of the
|> > package must preserve if the package is to continue to function
|> > correctly.

You responded: 

|> Agreed. This is true no matter how you implement derived classes.

If child packages are forbidden by convention and all of the exported
operations are understood to be a part of the documented interface (i.e.,
their inclusion in the interface represents a commitment that they will
continue to be supported in future versions of the package) and the
operations preserve the necessary invariants, then in fact it is not a
concern:  Any subclass or ordinary client using the class is doing so in
a supported manner.

|> > Back to the idiom you propose:  The usual reason for a derived class
|> > referring directly to members of a base class is efficiency.
|>
|> You can gain efficiency in my scheme by inlining subprograms.

True.

|> > If you are
|> > going to force all manipulations of the base-class implementation to be
|> > through subprograms exported by Base_Package.Derived anyway, you lose the
|> > motivation for giving implementations of derived classes special
|> > privileges. Why distinguish then between operations that are acceptable
|> > only for derived classes to perform and those that are acceptable for all
|> > clients to perform?  If you have truly hidden the implementation of the
|> > base class from derived classes, then it would seem that any operation
|> > deemed safe for the implementation of the derived class to perform will
|> > also be safe enough for the world at large to perform.  If you have a
|> > specific example that suggests otherwise, it would be interesting to
|> > see it.
|>
|> To cite [Rumbaugh, Object Oriented Modeling & Design, 1991 (p.322)],
|> (hope I got the name right:-), and this the intention behind my proposal: 
|>
|> "....
[first paragraph of quote deleted]
|>
|> Often it is useful to write some "private" operations that are for
|> internal use only by other methods of the same class. It is desirable
|> to restrict the visibility of these operations so that other classes
|> cannot use them.  It is often necessary to allow subclasses to access
|> these internal operations, so a simple distinction between public and
|> private is not possible..."

It is the second sentence above that I question.  If your goal is to make
the world safe for subclass writers, then these "internal-use" operations
had better respect the invariants of the implementation.  If they do so,
what is the harm in making them available to the world at large?  After
all, if they are potentially useful to implementers of subclasses, they
are potentially useful to ordinary clients as well.

That avoids the complications of writing a special child package for use
by subclasses only, ensuring that these special child packages are the
only child packages (ensuring that there are NO child packages is simpler
matter), and ensuring that these special child packages are imported only
to implement subclasses.

Again, I would be interested in seeing a compelling specific
counterexample.

|> Thank you for your answer, Norman.  Although it didn't convince me to
|> drop my proposal it was interesting to hear your opinions.  May I add
|> a congratulation for your really fine book "Ada as a 2nd language"?

Thank you!

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: OO Idiom: Interfaces for derived classes

[Jean-Pierre Rosen]

At 15:34 21/03/1996 +0100, you wrote:
>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.
We discussed this issue at length during some Ada-France meeting. Here is a
summary of our conclusions.

There are two views of derived classes. Suppose you are the provider of some
reusable software components, and you want to provide guarantee on your product.

1) The product as a whole is a hierarchy of classes (for example, a set of
widgets).  For design as well as for efficiency reasons, it makes sense to
have derived classes defined in child packages, and since it is YOUR
product, you don't mind derived classes accessing the parent's private part.
Actually, without hierarchical libraries, you would provide the  whole stuff
as one package. Child packages make it just more convenient  for the user to
"with" only the features that are needed.

2) The product is a set of classes, that are INTENDED to be extended by the
user. The user should not do this in child packages, because you cannot
guarantee your product if the *user* accesses the private part of the
parent. Actually, the  guarantee would have a clause "guarantee is void if
classes are derived in child packages", similar to a TV set with a clause
"guarantee is void if the user opens the back pannel".

So both views serve are useful, for different purposes.
+------------------------------------o-------------------------------------+
| P-mail:                            | E-mail: rosen@enst.fr               |
|   ADALOG - 27 avenue de Verdun     |    Tel: +33 1 46 45 51 12           |
|   92170 Vanves - FRANCE            |    Fax: +33 1 46 45 52 49           |
+------------------------------------o-------------------------------------+

Re: OO Idiom: Interfaces for derived classes

[Norman H. Cohen]

In article <199603220939.KAA00777@email.enst.fr>, Jean-Pierre Rosen
<rosen@EMAIL.ENST.FR> writes: 

|> There are two views of derived classes. Suppose you are the provider of some
|> reusable software components, and you want to provide guarantee on your product.
|>
|> 1) The product as a whole is a hierarchy of classes (for example, a set of
|> widgets).  For design as well as for efficiency reasons, it makes sense to
|> have derived classes defined in child packages, and since it is YOUR
|> product, you don't mind derived classes accessing the parent's private part.
...
|>
|> 2) The product is a set of classes, that are INTENDED to be extended by the
|> user. The user should not do this in child packages, because you cannot
|> guarantee your product if the *user* accesses the private part of the
|> parent. Actually, the  guarantee would have a clause "guarantee is void if
|> classes are derived in child packages", similar to a TV set with a clause
|> "guarantee is void if the user opens the back pannel".

Yes, this is a very useful distinction.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: OO Idiom: Interfaces for derived classes

[Gerd Moellmann]

Jean-Pierre Rosen <rosen@EMAIL.ENST.FR> writes:

> At 15:34 21/03/1996 +0100, you wrote:
> >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.
> We discussed this issue at length during some Ada-France meeting. Here is a
> summary of our conclusions.
> 
> There are two views of derived classes. Suppose you are the provider of some
> reusable software components, and you want to provide guarantee on your product.
> 
> 1) The product as a whole is a hierarchy of classes (for example, a set of
> widgets).  For design as well as for efficiency reasons, it makes sense to
> have derived classes defined in child packages, and since it is YOUR
> product, you don't mind derived classes accessing the parent's private part.
> Actually, without hierarchical libraries, you would provide the  whole stuff
> as one package. Child packages make it just more convenient  for the user to
> "with" only the features that are needed.
> 
> 2) The product is a set of classes, that are INTENDED to be extended by the
> user. The user should not do this in child packages, because you cannot
> guarantee your product if the *user* accesses the private part of the
> parent. Actually, the  guarantee would have a clause "guarantee is void if
> classes are derived in child packages", similar to a TV set with a clause
> "guarantee is void if the user opens the back pannel".
> 
> So both views serve are useful, for different purposes.

I fully agree with the second paragraph, of course, but I think that
the first approach is really only useful under rare circumstances: The
reason is that I view the class hierarchy developers as just another
set of users of that hierarchy.  For a non-trivial, evolving class
hierarchy the second approach will bring the same benefits during
library development that it has when the library is shipped: we
avoid the void guarantee.






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