* Re: abstraction and encapsulation (Re: Will Java kill C++?) [not found] ` <TMB.96May12171849@best.best.com> @ 1996-05-13 0:00 ` Richard Riehle 0 siblings, 0 replies; 3+ messages in thread From: Richard Riehle @ 1996-05-13 0:00 UTC (permalink / raw) To: . 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <TMB.96May13085010@best.best.com>]
* Re: abstraction and encapsulation (Re: Will Java kill C++?) [not found] ` <TMB.96May13085010@best.best.com> @ 1996-05-15 0:00 ` John English 1996-05-16 0:00 ` Richard Riehle 0 siblings, 1 reply; 3+ messages in thread From: John English @ 1996-05-15 0:00 UTC (permalink / raw) . (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..." ---------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: abstraction and encapsulation (Re: Will Java kill C++?) 1996-05-15 0:00 ` John English @ 1996-05-16 0:00 ` Richard Riehle 0 siblings, 0 replies; 3+ messages in thread From: Richard Riehle @ 1996-05-16 0:00 UTC (permalink / raw) To: John English 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1996-05-16 0:00 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Dq3984.KBD@news.hawaii.edu> [not found] ` <4mgcgn$au4@newsbf02.news.aol.com> [not found] ` <4mjem8$q4k@colossus.holonet.net> [not found] ` <TMB.96May12171849@best.best.com> 1996-05-13 0:00 ` abstraction and encapsulation (Re: Will Java kill C++?) Richard Riehle [not found] ` <TMB.96May13085010@best.best.com> 1996-05-15 0:00 ` John English 1996-05-16 0:00 ` Richard Riehle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox