From: Kuba Ober <ober.14@osu.edu>
To: caml-list@yquem.inria.fr
Subject: C++/C# inheritance is bad?
Date: Fri, 16 Jan 2009 10:18:50 -0500 [thread overview]
Message-ID: <FCB84B14-903B-4DC9-949E-F4190C6D4873@osu.edu> (raw)
Yaron Minsky wrote a while ago that "When we first tried switching
over from VB to C#,
one of the most disturbing features of the language to the partners
who read the code
was inheritance. They found it difficult to figure out which
implementation
of a given method was being invoked from a given call point, and
therefore
difficult to reason about the code.".
I was always puzzled about such an argument. Scott Meyers points
out at every opportunity that in C++ (and, by extension, in OO languages
in general), the class's interface is a contract that has to be upheld
within
the inheritance tree. So if something is a Foo, then it must not
matter that
it's an instance that derives 5 levels deep from Foo. If the code is
written
such that a derived class breaks the contract, the code is written
wrongly
and will cause no end of trouble. It's another story, of course, how
to uphold such contracts in your development environment: how much
can the compiler do, how much can the test harness do, how much
is done via static code analysis tools, etc.
Most importantly, inheritance has never meant to be a way to reduce the
amount of code. It's an incidental benefit, often cited as somehow the
raison
d'etre of OO. If code reuse stands in the way of upholding the interface
contract, the contract wins in spite of code duplication. The best
example,
perhaps, is the *widely abused* circle/ellipse inheritance. The fact
that,
mathematically, a circle is an ellipse, does *not* mean that in OO
language
you should derive a circle class from an ellipse class -- it makes no
sense
at all if you think about it from the standpoint of interface
contracts. In OO
world, a circle is *not* an ellipse. An ellipse has two radii, a
circle doesn't,
that's where the story ends. The Wikipedia article about that problem is
amusing in the numerous examples they show that could supposedly
"fix" it somehow. I have not seen any decent, maintainable C++ code
where
the Liskov's substitution principle was violated. I have violated it
myself in
my early years of learning C++, and I have only regretted it.
So, when correctly applied, what's so disturbing about inheritance?
You inherit
only where it makes sense, and if it makes sense then you don't care
about
which particular method is called: it's supposed to be safe.
Cheers, Kuba
next reply other threads:[~2009-01-16 15:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-16 15:18 Kuba Ober [this message]
2009-01-16 15:58 ` [Caml-list] " Richard Jones
2009-01-16 16:28 ` On the benefits of OO, Was: " Jan Kybic
2009-01-17 12:40 ` Oliver Bandel
2009-01-16 18:27 ` Raoul Duke
2009-01-16 21:42 ` Kuba Ober
2009-01-17 3:14 ` Sashan Govender
2009-01-17 14:07 ` Kuba Ober
2009-01-18 6:24 ` Stefano Zacchiroli
2009-01-17 13:27 ` Jon Harrop
2009-01-17 14:35 ` Kuba Ober
2009-01-17 16:59 ` Jon Harrop
2009-01-17 21:22 ` Kuba Ober
2009-01-17 22:17 ` Jon Harrop
2009-01-17 23:29 ` David Teller
2009-01-17 23:49 ` Jon Harrop
2009-01-19 16:22 ` Visitor in OCaml [was Re: [Caml-list] C++/C# inheritance is bad?] Yoann Padioleau
2009-01-19 16:41 ` blue storm
2009-01-19 17:49 ` Richard Jones
2009-01-19 17:52 ` Visitor in OCaml Christophe TROESTLER
2009-01-21 20:09 ` Yoann Padioleau
2009-01-22 4:03 ` [Caml-list] " Yaron Minsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FCB84B14-903B-4DC9-949E-F4190C6D4873@osu.edu \
--to=ober.14@osu.edu \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).