Re: abstraction and encapsulation (Re: Will Java kill C++?)

[Richard Riehle <rriehle@nunic.nu.edu>]

On 13 May 1996, . wrote:

> A fundamental problem of most object oriented languages is that they
> encapsulate behavior too much:

  Yes.  This was one of the annoying issues with the earlier Ada standard.
  It was both a strength and a weakness.  It has been fixed in some rather
  clever, and quite useful ways, in the new Ada 95 standard.


> you can't easily encapsulate behavior
> that depends on the internals of multiple objects ("friend" etc. are
> failed attempts to work around that).

  I think the operative phrase is, "Don't make 'friends' with C++."
  Invading an encapsulation via "friends" is the equivalent of breaking
  it. But I'm not sure there is any other way in C++.

> Another problem is that many
> entities in actual programs do not deserve to be "abstracted"; they
> should remain anonymous and largely unseen.

  Perhaps the issue is one of "levels of abstraction" rather than don't
  do abstraction.  Unfortunately, many languages do not provide a range of
  options for creating levels of abstraction.  Inheritance, by itself, may
  not be enough.

> Many of the more recent
> object oriented languages (C++, Java, etc.) force you to go overboard
> and provide named abstractions for something as trivial as multiple
> return values or a callback.

  Fortunately, Ada does not "force you to go overboard" in this way.
  "Sometimes", to quote Sigmund Freud, "a cigar is just a cigar."

  On the other hand, the practice of using named abstractions for
  everything is probably not evil. When used intelligently, it can
  make a design more extensible.  Sometimes we fail to realize, in our
  zeal for software reuse, that extensibility is just as important,
  maybe even more important, than reuse.  In this regard, all the OOP
  languages,  those you have named, plus Eiffel and Ada, work out
  pretty well.

  Richard Riehle