Is inheritance overrated?

[PWilmarth]

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
>> I don't know or understand the internal workings of my car (and I
>> never intend to know) but I still make use of it and enjoy its
>> benefits.
>
>And you are not a professional mechanic. If you were, and made such a
>claim, you would be seen as a rather pathetic figure.

Well, you know, that's the point. I'm not a professional mechanic and I don't
intend to be. And where did I imply I would make such a claim? It's amazing
to me how you can never make a salient point in less than 100 words. Does
your code suffer from this kind of bloat also?

I'm only amazed that you didn't cite a gazillion references in proper APA
format on top of it.

Get a life, Bill.

[Mike Mitchell]

On Tue, 10 Dec 2002 22:27:18 -0000, "Kunle Odutola"
<kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:

>Mike, are you really suggesting that a spoon (or a bottle opener, stick etc)
>is a "function"?.

So someone passes you a spoon in a restaurant, and you think, ah, an
OOP method! Street.Restaurant.Spoon.Stir, eh?!!

MM

[Ed Courtenay]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:nhaevuso07qq0ts7pi9v4kn8ee51d9rghh@4ax.com...
> On Tue, 10 Dec 2002 22:27:18 -0000, "Kunle Odutola"
> <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:
>
> >Mike, are you really suggesting that a spoon (or a bottle opener, stick
etc)
> >is a "function"?.
>
> So someone passes you a spoon in a restaurant, and you think, ah, an
> OOP method! Street.Restaurant.Spoon.Stir, eh?!!
>
> MM

Nope, probably more like:

Dim IStirrable drink As New RoadsideCafe.ImitationTea
Dim IStirrer stirrer As New RoadsideCafe.HorriblePlasticSpoonThing

drink.StirWith(stirrer);

[Kunle Odutola]

W.E. (Bill) Goodrich, PhD wrote:

>> Perhaps the "big thinkers" in computer science will find more
>> effective paradigms to approach problem-solving,
>
> They already have. The Next Big Thing in academia is AOP, which will
> do to OOP what OOP did to SSP.

AOP is *complements* OOP. It can't replace it.

>> but right now, this is the paradigm that the software world is
>> operating from. It's popular because it is useful.
>
> Absolute nonsense. It is "popular" because the academics have been
> teaching it as The One True Way for a while now.

Nope. Many academics feel that not much [primary] innovation has occured
since LISP/Simula really.

>> I don't know or understand the internal workings of my car (and I
>> never intend to know) but I still make use of it and enjoy its
>> benefits.
>
> And you are not a professional mechanic.

And you've stated more times than there are lines in your bloated replies
that most VB'ers are "non-programmers" [sic]

> If you were, and made such a
> claim, you would be seen as a rather pathetic figure.

That's what we thought when you made that claim.

> But you - like
> most of the other OOP apologists here - claim to be a professional
> programmer. The extent to which you proudly proclaim that you "don't
> know or understand the internal workings of" the code elements you
> are using (or worse, modifying) is the extent to which you proclaim
> yourself dangerously incompetent at your claimed profession.

Really?. How many professional *application* programmers knew or understood
or cared about the internals of their OS?. Are they all incompetent for not
firing up a debugger and stepping thru kernel code.?

>> You might be able to achieve some peace of mind if you would take
>> the same approach.
>
> Unlike those of you who seem compelled to try (however poorly) to
> defend OOP, he seems to already HAVE a large measure of peace of mind.

Most people here (like most of the rest of the s/w development world) use
OOP. They don't have to defend it. Mike's and your illusory peace of mind
seems to be based on avoiding OOP whilst still throwing around derogatory
remarks based on ignorance [or a strategy of overemphasizing extreme
positions].

Kunle

[Kunle Odutola]

Mike Mitchell wrote:

Nice try to snip relevant context from my post.

>> Mike, are you really suggesting that a spoon (or a bottle opener,
>> stick etc) is a "function"?.
>
> So someone passes you a spoon in a restaurant, and you think, ah, an
> OOP method! Street.Restaurant.Spoon.Stir, eh?!!

Nope. I repeat again, "A spoon is an object".

ShovelCrapIntoMikesPieHole() might be a method of a
MikeMitchellOOP*****inSpoon (which IS-A type of Spoon).

Kunle

[Mike Mitchell]

On Wed, 11 Dec 2002 12:40:20 -0000, "Ed Courtenay"
<replace-this-with-my-first-name@edcourtenay.co.uk> wrote:

>Nope, probably more like:
>
>Dim IStirrable drink As New RoadsideCafe.ImitationTea
>Dim IStirrer stirrer As New RoadsideCafe.HorriblePlasticSpoonThing
>
>drink.StirWith(stirrer);

Eh? A semicolon at the end of a VB statement? Shurely shome mishtake,
Mish Moneypenny?

Also, aren't you supposed to use parentheses all over the place? E.g.
Dim IStirrable drink As New RoadsideCafe.ImitationTea()

MM

[Mike Mitchell]

On Wed, 11 Dec 2002 12:56:20 -0000, "Kunle Odutola"
<kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:

>ShovelCrapIntoMikesPieHole() might be a method of a

Ya see! This fellah knows when to use parentheses!

>MikeMitchellOOP*****inSpoon (which IS-A type of Spoon).

Oops, nope! Wrong! He doesn't!

MM

[David Bayley]

Phil Weber wrote:

> > Your ContentItem base class stores the Type as a public
> > String property, which immediately indicates to me that you
> > are not really "using" inheritance (TypeOf is available if you
> > must examine the type).
>
> Perhaps "Type" isn't the best name for that field; I use it to
> indicate which user control to use to display the content. I could
> call it DisplayControl, would I be "using" inheritance then? ;-) Or I
> suppose I could give the user control the same name as the associated
> content class, then use GetType to retrieve the name. The problem
> with that is that eventually our Web designers should be able to
> create the display controls; they shouldn't have to know or care
> about my class names.

Yes, I misunderstood the purpose of the "Type" property
("DisplayControl" would be clearer). In that case, it is preferable
that your business tier not have *any* dependancy on the presentation
tier, whether through direct references or string properties.

It is up to the presentation tiers to determine which controls are
associated with whatever biz objects they depend on, rather than the
other way around. Consider a rich Windows.Forms app (for example an
internal maintenance app) running along side your public Web.Forms
app... should the Biz.ContentItem then add a WindowsDisplayControl
property along side the (Web)DisplayControl property?

> > Say, for example, you refactored your data store into an
> > RDBMS with a "base" ContentItem table indexing all the ID's,
> > and various HomePage, FeaureArticle, ProductReview, etc.
> > tables with a foreign-key relation to the ContentItem table...
> > Would the problems you raised be any different?
>
> Yes, they'd be different. Instead of being able to reuse a single
> Load and Save method for all content classes, I'd have to write
> separate stored procedures and data access code for each class, and
> maintain a separate table for each content type. A LOT more work.

I think you misunderstood me here. The issue I was trying to raise, is
that refactoring the database to mirror the changes you made in the
application domain, would result in the same problems. Seperate
tables/classes, with the associated seperate client
stored-procedures/user-controls.

RDBMS's don't do inheritance, so this suggests that the issue is a more
fundamental one about the data domain (seperate tables), rather than the
behavioural domain(seperate classes) which usually feeds off the data.

> > On the subject of creating a Content Management System,
> > I think you are in danger of creating a generic framework...
>
> That's exactly what I'm doing. Why is that a danger? FTP wants a
> framework that it can use with its existing family of sites, as well
> as any new sites it may decide to launch in the future.

"Any" site? Some dangers that come to mind...

- You end up competing with 3rd-party generic framework providers, with
the major disadvantage that you only have *one* customer. If
3rd-parties are expensive, then that is an indication that the framework
is not so easy to produce in-house.

- Predicting future usage is inherently dangerous. The XP acronym YAGNI
(You Ain't Gonna Need It), comes to mind. More often, it is better to
refactor in new requirements when, and only when, they are required.
Continuous refactoring is suprisingly painless IME (it works first
time).

- A generic framework adds a layer of complexity to development. An IDE
is able to automatically provide class views, compile-time errors, UML
diagrams, intellisense, etc., for behaviour which is encoded in static
language constructs. A generic framework that uses proprietary strings
sacrifices much of this functionality.

- The original author may get run over by a bus. This is rather harsh,
but if I was employed to replace you, I could understand well named
classes written in language X. I won't understand a proprietary
framework unless you have gone to the exceptional expense of supporting
and documenting it in the same way that 3rd-party providers do.

> > Chances are some 3rd-party has already gone to far more
> > effort at writing a generic CMS that you can customize using
> > your XML form definitions.
>
> If you know of such a product, please feel free to recommend it. :-)

I admit I don't have any experience in the CMS market. If there is one
though, then chances are somebody will be able to provide an economical
generic framework now, or in the future. Until then, better to write a
self-documenting maintainable Fawcette System using well known language
structures.

> > It only takes an hour to derive a few HomePageItem* classes,
> > and subsequently minutes to modify HomePageItem behaviour.
>
> That's an hour + minutes that I won't have to spend maintaining my
> generic framework. The users can create a new content type without my
> involvement, simply by creating a user control to display the
> content, an XML edit form definition, and adding a row to a
> ContentTypes table.

Why do *you* have to implement this in the generic framework. There are
gazillions of programmers capable of inheriting from .NET classes, but
there is only one programmer who understands your form definition files
(XML alone is just hierarchical text).

All you have to do is provide a set of base Web and/or Windows Controls.
Sure they will have a *similar* structure to the server Biz objects, but
seperating these logical tiers is usually worth it because of the
different behaviour these similarly named classes implement.
Alternatively, just start off implementing all the behaviour in
Web.Controls, and refactor out a business tier as needed (there is no
law that says n-tier is needed).

--
David