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

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

[Richard Riehle]

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

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

[John English]

. (tmb@best.com) wrote:
: In my experience, making designs extensible takes time and effort.  It
: also makes the design harder to understand for other people.  That
: cost is worth it if you plan on reusing that software.  But a lot of
: software doesn't need to be reused, however.  [...snip...]

Extensibility is important for maintenance too; a lot of maintenance
changes involve adding extra bells and whistles which can be a major
problem if extensibility *wasn't* designed for.  This (IMHO) is a
much more important consideration than reuse, which as you said is
something that isn't needed that often.

-- 
----------------------------------------------------------------------------
John English <je@brighton.ac.uk>, Dept. of Computing, University of Brighton
  "Disks are divided into sex and tractors..."
----------------------------------------------------------------------------

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

[Richard Riehle]

On Wed, 15 May 1996, John English wrote:

> Extensibility is important for maintenance too; a lot of maintenance
> changes involve adding extra bells and whistles which can be a major
> problem if extensibility *wasn't* designed for.  This (IMHO) is a
> much more important consideration than reuse, ...

  Exactly.

  As a software product ages, more of the maintenance (Meyer cites a
  study showing 42%) is devoted to extending that product with new
  features than any other single activity.  In conversations with
  other developers, and based on personal experience, I believe
  that maintenance of a mature software product is closer to
  75% to 80% new features.

  The important thing is to add these new features without breaking
  the existing product. Before OOP, this was the equivalent of
  open-heart surgery, and the mortality rate of the software was
  about the same as one expects from such surgery.

  How do we extend an existing product without breaking it. Inheritance
  is one mechanism.  It is not enough, but it is important. Ada 95
  provides some additional mechanisms, as does Eiffel.  C++ is a little
  frail in this regard, but it is better than what we have had in the
  past.  The reality is that we are a long way off from fully satisfying
  the demands of extensibility.  Yet this is where the long-term
  economic benefits are hidden.

  Richard Riehle