--ATCcdtClfT3OTXr4aSU
Content-Type: multipart/alternative; boundary="=-a5Y6GSRzGWi4pCIIf3nq"


--
5Y6GSRzGWi4pCIIf3nq
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).

-- 
Michael T. Richter <ttmrichter / gmail.com> (GoogleTalk:
ttmrichter / gmail.com)
A well-designed and humane interface does not need to be split into
beginner and expert subsystems. (Jef Raskin)

--
5Y6GSRzGWi4pCIIf3nq
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.12.1">
</HEAD>
<BODY>
On Sun, 2007-07-10 at 07:21 +0900, Austin Ziegler wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">I'd say it should be avoided 98% of the time (MI). Inheritance in</FONT>
<FONT COLOR="#000000">general, is probably overused by at least 50%. (Most is-a</FONT>
<FONT COLOR="#000000">relationships aren't useful ones and are caused by people who aren't</FONT>
<FONT COLOR="#000000">used to thinking of OOP in other terms. I'm not suggesting this for</FONT>
<FONT COLOR="#000000">you, but is-a has a lot of implications that has-a doesn't. Therefore,</FONT>
<FONT COLOR="#000000">it's not &quot;you-should-not-use-inheritance crap&quot;, it's sound advice from</FONT>
<FONT COLOR="#000000">years in the industry.)</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Going back to the original model that sparked this: inheritance reflects anquot;is-a&quot; relationship.&nbsp; Someone wants to make an application object that:
<OL TYPE=1>
    <LI TYPE=1 VALUE=1>IS-A Linux application; and
    <LI TYPE=1 VALUE=2>IS-A video player application.
</OL>
<BR>
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?&nbsp; Just the &quot;LinuxApplication&quot; class by itself makes me suspicious of the model behind it: what useful abstraction doou get from this that you don't get from an &quot;Application&quot; that has a &quot;POSIXFileSystem&quot; (instead of &quot;NTFSFileSystem&quot;) and a &quot;LinuxSecurityModel&quot; (instead of &quot;NTSecurityModel&quot;) or whatever?&nbsp; Just this core has me scratching my head.<BR>
<BR>
Adding the &quot;VideoPlayerApplication&quot; 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?&nbsp; A VideoRecorderApplication?&nbsp; An AudioPlayerApplication?&nbsp; A RealTimeAutomobileAssembleyApplication?<BR>
<BR>
Basically, I'm failing to see any useful &quot;IS-A&quot; relationships at all in the original poster's model barring an awfully convoluted run-time with some questionable approaches to things built into it.&nbsp; What he's viewing as inheritance (IS-A) situations to me look like composition (HAS-A)ituations.<BR>
<BR>
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 <B>lousy</B> at supporting HAS-A relationships (and Java isn't much better).<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
<B>Michael T. Richter</B> &lt;ttmrichter / gmail.com&gt; (<B>GoogleTalk:</B> ttmrichter / gmail.com)<BR>
<I>A well-designed and humane interface does not need to be split into beginner and expert subsystems. (Jef Raskin)</I>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--
5Y6GSRzGWi4pCIIf3nq--

--ATCcdtClfT3OTXr4aSU
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
LLqZveVwGD4fZ460VmoPUoU5Z
-----END PGP SIGNATURE-----

--ATCcdtClfT3OTXr4aSU--