Xref: utzoo comp.lang.eiffel:1385 comp.object:2524
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Message-ID: <1991Feb7.102231.7672@tukki.jyu.fi>
Date: 7 Feb 91 10:22:31 GMT
References: <485@eiffel.UUCP> <488@eiffel.UUCP> <1991Feb4.223823.3198@runx.oz.au>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 50

In article <1991Feb4.223823.3198@runx.oz.au> chrisv@runx.oz.au (Chris Velevitch) writes:
> ...
>Yes I agree that abstraction is the real goal of OOD. I get the feeling
>exporting features is a smoke screen. Would it not be better to simply make
>all features of a class implicitly public (as in Smalltalk)? This would free
>the designer from having to think about what features would be useful to
>clients and help concentrate on what the interface should be in the context
>of the problem.

I agree with the designers of the majority of newer OOPL's that the
Smalltalk way is worse.  It's exactly the question about the interface.
Following Ole-Johan Dahl, the grand old man of OOP, think of objects
or classes offering an interface of procedures (methods) to potential clients,
as an analogy of procedures (in a subroutine library, say) offering
an interface of formal parameters to potential invokers.

The definitions of formal parameters are important to the invokers
of a procedure, but most procedures also contain local variables
that are none of the invokers' business.  Likewise, the definitions
of public operations are important to the clients of a class,
but some private operations may well be useful to implement the
public ones.  In most cases they could be eliminated by code duplication
(contrary to the code reuse goal of OOP),  but that is not possible
if a private procedure is recursive.

If the class designer later notes that some originally private feature
should be offered to clients, he can simply change it from private to public.
From the clients' viewpoint it is exactly equivalent with adding
a brand-new feature to the class.  Our procedure analogy does not work
very well here any longer, but in some languages the formal parameter list
of a procedure can be extended with optional parameters without disrupting
existing code.

I support the "orthogonal" view to visibility that is taken e.g. by
current Simula and C++, that even instance variables can be declared
public or private (or "protected").  Of course, declaring a public instance
variable in a class is a strong commitment that restricts the freedom
in the implementation and evolution of the class, but a class designer
should have the possibility to such a commitment.  _Any_ public feature
constitutes a commitment and restriction, especially if its declaration
promises something about its semantics (like the assertions of Eiffel)
instead of containing only the signature.

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)