From: "Michael T. Richter" Date: 2007-10-07T14:13:36+09:00 Subject: Re: The Case for Multiple-Inheritance --=-8ATCcdtClfT3OTXr4aSU Content-Type: multipart/alternative; boundary="=-a5Y6GSRzGWi4pCIIf3nq" --=-a5Y6GSRzGWi4pCIIf3nq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2007-07-10 at 07:21 +0900, Austin Ziegler wrote: > I'd say it should be avoided 98% of the time (MI). Inheritance in > general, is probably overused by at least 50%. (Most is-a > relationships aren't useful ones and are caused by people who aren't > used to thinking of OOP in other terms. I'm not suggesting this for > you, but is-a has a lot of implications that has-a doesn't. Therefore, > it's not "you-should-not-use-inheritance crap", it's sound advice from > years in the industry.) Going back to the original model that sparked this: inheritance reflects an "is-a" relationship. Someone wants to make an application object that: 1. IS-A Linux application; and 2. IS-A video player application. What stymies me here is... exactly which runtime is this going to be running in where you can plug in a Linux application, a Windows application or a ... Symbian, say, application and need the transparent dispatching to the right functionality? Just the "LinuxApplication" class by itself makes me suspicious of the model behind it: what useful abstraction do you get from this that you don't get from an "Application" that has a "POSIXFileSystem" (instead of "NTFSFileSystem") and a "LinuxSecurityModel" (instead of "NTSecurityModel") or whatever? Just this core has me scratching my head. Adding the "VideoPlayerApplication" to the mix only raises even more questions, all related, once again, to the nature of a runtime where you need transparent dispatching to a VideoPlayerApplication over ... what, exactly? A VideoRecorderApplication? An AudioPlayerApplication? A RealTimeAutomobileAssembleyApplication? Basically, I'm failing to see any useful "IS-A" relationships at all in the original poster's model barring an awfully convoluted run-time with some questionable approaches to things built into it. What he's viewing as inheritance (IS-A) situations to me look like composition (HAS-A) situations. And this is what strikes me about most C++ code: people using IS-A left, right and centre because that's what the language supports best; C++ is positively lousy at supporting HAS-A relationships (and Java isn't much better). --=20 Michael T. Richter (GoogleTalk: ttmrichter@gmail.com) A well-designed and humane interface does not need to be split into beginner and expert subsystems. (Jef Raskin) --=-a5Y6GSRzGWi4pCIIf3nq Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun, 2007-07-10 at 07:21 +0900, Austin Ziegler wrote:

I'd say it should be avoided 98% of the time (MI). =
Inheritance in
general, is probably overused by at least 50%. (Mos=
t is-a
relationships aren't useful ones and are caused by =
people who aren't
used to thinking of OOP in other terms. I'm not sug=
gesting this for
you, but is-a has a lot of implications that has-a =
doesn't. Therefore,
it's not "you-should-not-use-inheritance crap&=
quot;, it's sound advice from
years in the industry.)

Going back to the original model that sparked this: inheritance reflects an= "is-a" relationship. Someone wants to make an application = object that:

IS-A Linux application; and
IS-A video player application.

What stymies me here is... exactly which runtime is this going to be runnin= g in where you can plug in a Linux application, a Windows application or a = ... Symbian, say, application and need the transparent dispatching to the r= ight functionality? Just the "LinuxApplication" class by it= self makes me suspicious of the model behind it: what useful abstraction do= you get from this that you don't get from an "Application" that = has a "POSIXFileSystem" (instead of "NTFSFileSystem") a= nd a "LinuxSecurityModel" (instead of "NTSecurityModel"= ) or whatever? Just this core has me scratching my head.

Adding the "VideoPlayerApplication" to the mix only raises even m= ore questions, all related, once again, to the nature of a runtime where yo= u need transparent dispatching to a VideoPlayerApplication over ... what, e= xactly? A VideoRecorderApplication? An AudioPlayerApplication?&= nbsp; A RealTimeAutomobileAssembleyApplication?

Basically, I'm failing to see any useful "IS-A" relationships at = all in the original poster's model barring an awfully convoluted run-time w= ith some questionable approaches to things built into it. What he's v= iewing as inheritance (IS-A) situations to me look like composition (HAS-A)= situations.

And this is what strikes me about most C++ code: people using IS-A left, ri= ght and centre because that's what the language supports best; C++ is posit= ively lousy at supporting HAS-A relationships (and Java isn't much b= etter).

--
Michael T. Richter <ttmri= chter@gmail.com> (GoogleTalk: ttmrichter@gmail.com)
A well-designed and humane interface does not need to be split into begi= nner and expert subsystems. (Jef Raskin)

--=-a5Y6GSRzGWi4pCIIf3nq-- --=-8ATCcdtClfT3OTXr4aSU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBHCGryLqyWkKVQ54QRApPgAJ4iAujVDnsv3M9JhzEAbTQ3uLLEpgCaAo/p LLqZveVwGD4fZ460VmoPUoU= =pz5Z -----END PGP SIGNATURE----- --=-8ATCcdtClfT3OTXr4aSU--