Is inheritance overrated?

[Arthur Wood]

<CLIP>
BTW, Arthur, what happens when the child becomes an adult?
</CLIP>

good point, but the situation never arose - that Church has since closed
its doors, and it would most likely have been the case that in the case where
a child DID reach 'adulthood', they would have been added to the app as a
'New' Family unit (either with a College address, or ore likely, a different
address fromn their parent's address). Even if they still lived at 'home',
the elders of the chirch wanted to treat 'adult' children as a separate 'family
unit'. In that case, the only information that would need to be re-entered
would have been Birthdate (no biggy).

Artur Wood

[Mike Mitchell]

On 3 Dec 2002 06:49:41 -0800, "Arthur Wood" <wooda@nospam.com> wrote:

>But so far, in almost 5 years of app development at the professional level,
>this was the only REAL application where I found inheritance to be really
>useful.

But, Arthur, even then, why do it like that at all? Too much
complexity again! You could write a membership management proggie like
that in half a day with just an Access database, a data control, and a
grid. It would be as simple as heck and there would be nothing
inferior about the program thus produced.

I believe many programmers start in on OOP for all the wrong reasons,
e.g. they think they will gain some respect from the gurus. I'm not
saying you did that, but I am always reading about failed projects
nowadays. And ten to one they (or some of them) are being done with
rigid attention to OOP diktat. I'm pretty certain some failures
wouldn't have happened if only the coders could just learn to keep it
simple.

MM

[Kunle Odutola]

> I believe many programmers start in on OOP for all the wrong reasons,
> e.g. they think they will gain some respect from the gurus. I'm not
> saying you did that, but I am always reading about failed projects
> nowadays.

Unlike in the good old days before OOP came along right Mike?
When project never failed?

LOL!

Kunle

[Jason Sobell - iGadget]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:qjruuukg4cb0scch3tt6e1i4cf6p9kcrv2@4ax.com...
> On 3 Dec 2002 06:49:41 -0800, "Arthur Wood" <wooda@nospam.com> wrote:
>
> >But so far, in almost 5 years of app development at the professional
level,
> >this was the only REAL application where I found inheritance to be really
> >useful.
>
> But, Arthur, even then, why do it like that at all? Too much
> complexity again! You could write a membership management proggie like
> that in half a day with just an Access database, a data control, and a
> grid. It would be as simple as heck and there would be nothing
> inferior about the program thus produced.

Having the _choice_ of coding in a structured fashion or not is what is
introduced in .NET.
You can still bodge up code in procedural fashion if you want to keep
writing code the way you have in VB6

> I believe many programmers start in on OOP for all the wrong reasons,
> e.g. they think they will gain some respect from the gurus.

Very true. Lots of people do indeed think that OOP is some sort of 'ivory
tower', but when you consider some of the advantages of OO development
(which I know you dispute all of) I think it is very healthy to understand
_all_ methods of development so you can swap and choose between them.
I use VB6 for small, easy delivery 'utilities' where I want to develop a
'no-brainer'. I use .NET for anything of complexity where I intend
modifying, reusing, or sharing any of the system.

> I'm not
> saying you did that, but I am always reading about failed projects
> nowadays. And ten to one they (or some of them) are being done with
> rigid attention to OOP diktat.

It's not OOP diktat, it's a complete lack of understanding of the problem
that causes so many failures.
Methodologies such as Rational's attempted to address the issue, but were
too heavyweight, and lets face it - we can't force weak programmers with no
problem solving skills to develop a good solution no matter how many 'Use
case scenarios' we get them to write

> I'm pretty certain some failures
> wouldn't have happened if only the coders could just learn to keep it
> simple.

Absolutely, but this is a difficult concept to grasp. An OO structure for a
solution is inherently (sic) more difficult for habitual procedural
developers to grasp than simply to 'hack up' some working code. Both of
these are possible in .NET, as in almost any OO language (such as 'C' code
written in C++).
The trick is _finding_ the simple solution in VB.NET. If you practise, you
can find one and write a solution with very little complexity very quickly.
Yes, the same applies to VB6, but you generally end up with lots of variant
type situations where it can't quite meet your requirements for generic
handling of a situation.

Cheers,
Jason

[Michael Culley]

> And ten to one they (or some of them) are being done with
> rigid attention to OOP diktat. I'm pretty certain some failures
> wouldn't have happened if only the coders could just learn to keep it
> simple.

Usually the first project a company or programmer does in oop fails, after
that initial hurdle I think oop is a good thing. You are correct in stating
some of its disadvantages, it does need more advanced developers and is a
little more complex. You think it is hugely complex just because you have
never done it (everything seems complex before you do it), however, it is
simpler and easier than you think.

--
Michael Culley

[Jason Smith]

Mike, it is clear you still don't understand how to use OO.

You can open a beer bottle with a hammer, but not with the part you use to
drive in nails. Understand? No? I'm not surprised.

OO is a set of tools. Not all of them are always applicable, and sometimes
none of them are. If you use them incorrectly, you end up with a broken
bottle and beer all over the floor. Uh, sorry, back to the hammer analogy.
If you use them correctly, you get the beer and keep your teeth.

But okay, Mike, if you want to go on hammering nails in with that big flat
forehead of yours, and opening beer bottles with your teeth, go right ahead.
Heck, if someone gave you a hammer, you would probably just use it to test
how strong your skull is anyway.


"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:qjruuukg4cb0scch3tt6e1i4cf6p9kcrv2@4ax.com...
> On 3 Dec 2002 06:49:41 -0800, "Arthur Wood" <wooda@nospam.com> wrote:
>
> >But so far, in almost 5 years of app development at the professional
level,
> >this was the only REAL application where I found inheritance to be really
> >useful.
>
> But, Arthur, even then, why do it like that at all? Too much
> complexity again! You could write a membership management proggie like
> that in half a day with just an Access database, a data control, and a
> grid. It would be as simple as heck and there would be nothing
> inferior about the program thus produced.
>
> I believe many programmers start in on OOP for all the wrong reasons,
> e.g. they think they will gain some respect from the gurus. I'm not
> saying you did that, but I am always reading about failed projects
> nowadays. And ten to one they (or some of them) are being done with
> rigid attention to OOP diktat. I'm pretty certain some failures
> wouldn't have happened if only the coders could just learn to keep it
> simple.
>
> MM

[Ian Lowe]

Hi, Phil,

It looks to me that the problem wasn't with inheritance, but rather that
your first design simply wasn't a good match for your requirements.
Specifically, it seems that you required a very generic content management
system that can accept new types of content items at run-time without
intervention of a programmer. In this case, requiring a specific class for
each content type just doesn't match the requirements, whether using
inheritance or not.

Is this a common problem with inheritance? It depends on how you look at it.
In general, implementation inheritance is a type of specialisation where
subclasses present more specialised versions of a more generic parent.
Consider, for example, the WinForms controls which present more and more
specialised controls all inheriting ultimately from Windows.Forms.Control.
In this sense, inheritance leads to specialisation so inheritance will only
aid your design if specialisation can help. In your specific case, you want
the opposite of specialisation for your content items; you want flexible,
run-time genericity.

On the other hand, one purpose of implementation inheritance is to allow for
code re-use. If you have a group of related classes that all need to
implement the same, non-trivial code, those classes may be good candidates
for a refactoring into an inheritance hierarchy. This does not appear to be
the case in your example.

As a general rule-of-thumb, implementation inheritance is most helpful with
the creation of frameworks and has less to offer for specific applications.
In the latter case, interfaces may be all that is required.

Ian.

[Jon C. Stonecash]

"Willy Van den Driessche" <wvddwebcomments@skynet.be> wrote:

>> Another possibility that I considered was to place the common logic
>> into a validation driver class, define a virtual parent for the
>> validation specifics class that defined the map, validate, and convert
>> methods, and then define children of that specifics class for each
>> data type that needed to be validated. I did not do that because I
>> found that there was a lot of overlap in the helper methods for each
>> data type.
>Could you please elaborate why an interface would not have been much better
>? I don't see so many common functionality inside typical "validators".
>Aren't the common (protected) methods hidden static methods that are
>actually usable outside of validators too ?

Sorry for the delay. I was out of town on business and did not have
time to check these newsgroups.

I could have done this with interfaces, but the class design that I am
using for the validation has a fair amount of internal state. Any
interface would have to pass a fair number of parameters to allow the
interface to do the job. It was easier to make these protected fields
and inherit from the validator. Not better, just easier.

Your comment about reusing some of the common methods rings true. One
of the bugs that I chased this week in this project resulted from
using a validator before one of the dependencies that the validator
class requires had been set up. If I had a little more time, I might
have done some refactoring to isolate things a bit better.

This project is essentially over for me, and like every project that I
have ever done, has things done one way that I think could have been
done differently and better. If I only knew then what I know now.
The design of the project is solid and represents a significant step
up for the client, but given a few more days/weeks (dollars!), I could
have made it ever so much better!

Jon Stonecash

Jon C. Stonecash, Rainier Technology
Internet: stonecash@cdev.com, Compuserve: 73014,1255

[Mike Mitchell]

On Fri, 6 Dec 2002 08:34:11 +1100, "Jason Sobell - iGadget"
<iGadget_@hotmail.com> wrote:

>......... An OO structure for a
>solution is inherently (sic) more difficult for habitual procedural
>developers to grasp than simply to 'hack up' some working code.

Not just for habitual proceduralists, but for everyone. OOP is
inherently more difficult, period. That is its problem. For where its
applicability can be of use in certain esoteric problem solving, for
business applications it's mostly hopeless overkill. There is nothing
complex about ordinary, everyday business practices. Folks have been
running businesses for centuries. The basics don't change. The
concepts of profit and loss, stocks and shares, buy and sell, product
development, cost management, and all the other standard business
practices do not change. What changes is that the old boys, often
without any formal qualifications, hang up their Hollerith cards and
die off, to be replaced by new, eager graduates fresh from academe who
take their place, their heads full of theory and empty of experience.
This is what business nowadays has to utilise. Hardly surprising, when
said graduates are fed on a diet of OOP and nothing but OOP, that they
will not want to employ OOP as the one hammer to crack any nut when
they are finally let loose upon an innocent public which still can't
fathom how to set up the VCR.

Pragmatism seems to have no place any longer. If it ain't OOP, it must
be POOP!

MM

[Mike Mitchell]

On Fri, 6 Dec 2002 09:39:47 +1100, "Michael Culley"
<mculley@NOSPAMoptushome.com.au> wrote:

>............ however, it is
>simpler and easier than you think.

No. Simpler and easier is how we all *do* think, and the natural,
simple, efficacious way we *do* think is not to think of a dog or a
cat being derived from a base "animal", or a tree having child
"branches" and branches to have child "twigs". It's all nuts. So
restrictive, so rigid, so intransigent. Completely unlike life as it
is really lived. With OOP architecture, every building would look like
another. Hey, fellah! Don't even think of building that east wall out
of timber! It's gotta be brick, the base class says so. Eh? You
"preferred" timber? What's preference got to do with anything? We only
inherit brick walls here, sonny.

Once we have finally woken up to the fact that even the emperor's
handlers now believe that the daft old bugger's naked, that's when we
can move on and redesign computing without designing in complexity,
just to make ourselves look bright. Those with the truly big intellect
always aim to keep it simple, because they know intrinsically that
simplicity always has a better chance of working than complexity. If
there's less to go wrong, there's less that can go wrong, and even if
it does, there's a lot less of it to unravel in order to find and fix
the problem.

MM

[Mike Mitchell]

On Thu, 5 Dec 2002 17:27:40 -0700, "Jason Smith" <jsmith@hotmail.com>
wrote:

>You can open a beer bottle with a hammer, but not with the part you use to
>drive in nails. Understand? No? I'm not surprised.

Ah! The mentality of an OOP aficionado, I see! And if I had no hammer,
but I was thirsty and had a stone? Why, I'd hit the bottle with the
stone and filter the contents through a sock. Trouble is, the stone
doesn't figure in your OOP hierarchy. I can quickly write a proc
"Stone" to deal with the situation as it is at this moment in time;
you must go back to your model and start doing some overloading,
overriding, subclassing, or whatever else it is that you OOP chaps do
to get a stone into that class model where previously it was a hammer!

MM

[Larry Serflaten]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
> On Fri, 6 Dec 2002 09:39:47 +1100, "Michael Culley"
>
> No. Simpler and easier is how we all *do* think, and the natural,
> simple, efficacious way we *do* think is not to think of a dog or a
> cat being derived from a base "animal", or a tree having child
> "branches" and branches to have child "twigs". It's all nuts. So
> restrictive, so rigid, so intransigent.

Do you play any sort of instrument? Each note in a song is precisely
defined, restrictive, rigid and on paper, is intransigent. Yet get two
musicians to play the same song, from the same sheet of music, and you'll
hear different things. How can that be, since they both are playing from
the same sheet of music?

You say we do not think of a dog being derived from a more base class,
but ask any child if a dog is an example of a plant or an animal and many
will give the right answer. There is an association.

The same for trees and branches, ask a child what a tree is made of, and you
will often hear wood. Ask the same child what a branch is made of and
what do you suppose the answer will be? It will more often be the same
answer they gave for the tree because a branch is a smaller part of a tree.

A child can see these associations, even if you refuse to acknowledge them.

>Completely unlike life as it is really lived. With OOP architecture, every
>building would look like another.

Exactly how do you suppose real life can be modeled in a world of 1's
and 0's? No way can it be exact, otherwise it would be a duplicate world.
But it is a representation that can be manipulated in the realm of 1's and 0's
and that is the realm which the engineers must work in.

It never ceases to amaze me how fantasitcally closed minded you are to
new ideas, or even a few variations. You are made up of cells, different
types of cells. The types of cells you have match the types of cells every
other human has, yet amazingly, we do not all look alike. Perhaps that
real world fact can open the blinders you have to how exact same object
patterns can be used to produce different results.

There is no such thing as a real world animal base class. But there is an
association among animals when they share common traits, or behaviours.
In the realm of 1's and 0's, how would you represent that association?

Being completely predictable, you would go about adding common properties
to all the structures that represent some kind of animal, and in the process
would be adding duplicate code to manage those properties, in all the
animal structures you ever build. But, come the day that you find you've
missed a common trait, you might spend the half your time on new projects
looking over older code to find where that extra trait has to be added in
any 'reused code'.

That's the problem. Its not that objects make programming easier to architect,
rather it makes new architects easier to incorporate. If you never have to
go back over old apps to add new functionality, you probably don't need to
look twice at OOP because you can get by without it. But if you have to
revisit code often, you'll want a common set of abstracted ideas that apply
to everything you look at so you can get up to speed on what it is doing
in a relatively short period of time. With objects, and object patterns, you
can grasp the intent of the code from familiarity of similar patterns.

Everything in life follows a pattern. You are even using patterns when you
start a For/Next loop. It is, after all, a conditional jump under the hood, but
it is a pattern used so often it is given easy to use syntax.

That is what OOA basically is, a means to abstract patterns from common
problems and their solutions. So what if you don't think patterns are useful,
you are in a world full of patterns, whether you like it or not. Every time you
open your mouth against the use of such patterns you stick both feet into it
because you can't get by in life without following some familiar patterns.

LFS

[PWilmarth]

Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>No. Simpler and easier is how we all *do* think, and the natural,
>simple, efficacious way we *do* think is not to think of a dog or a
>cat being derived from a base "animal", or a tree having child
>"branches" and branches to have child "twigs". It's all nuts. So
>restrictive, so rigid, so intransigent. Completely unlike life as it
>is really lived.

Well, your making the assumption that everyone in the world thinks like you
do. That is a pretty broad assumption and suggests a certain narrow-mindedness
on your part (but we already know this).The truth is that most of us do think
of things as types. Almost every discipline organizes things into types.
Why do we keep talking about a dog being a type of animal? Because many
smart Biologists (some of them were Brits) looked at "living things" and
organized them into types: Reptiles, Animals, Birds, Plants, etc.

>With OOP architecture, every building would look like
>another. Hey, fellah! Don't even think of building that east wall out
>of timber! It's gotta be brick, the base class says so. Eh? You
>"preferred" timber? What's preference got to do with anything? We only
>inherit brick walls here, sonny.

Keep talking, Mike. You keep showing your ignorance. I think that OOP provides
multiple ways of constructing a building that allows you to use different
building materials.

[PWilmarth]

Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
> And if I had no hammer, but I was thirsty and had a stone? Why, I'd hit
>the bottle with thestone and filter the contents through a sock. Trouble
>is, the stone doesn't figure in your OOP hierarchy. I can quickly write
a >proc "Stone" to deal with the situation as it is at this moment in time;
>you must go back to your model and start doing some overloading,
>overriding, subclassing, or whatever else it is that you OOP chaps do
>to get a stone into that class model where previously it was a hammer!
>
>MM

Mike, Mike, Mike, you are hopeless. A stone is a type of tool, just as a
hammer is. Ever study anthropology? Early man used stones as all types
of tools, some effectively, some less effectively. The user decides how he/she
implements that tool. I don't think that early man was even so foolish as
to keep re-inventing the wheel every time they needed a tool. In fact, I
think they learned how to fashion stones to be used as pretty specialized
types of tools.

If you want to go around bashing open beer bottles with a stone, that's
your business. I would rather wait until I found (or better yet, built)

a bottle opener. OOP just provides a way to describe (or build) your tool.

If you didn't have such a good sense of humor, I don't think any of us would
tolerate you at all. Sometimes, you're like my dotty old uncle . . . amusing,
but hardly worth taking seriously.

[Jason Sobell - iGadget]

"Mike Mitchell" wrote:

> >......... An OO structure for a
> >solution is inherently (sic) more difficult for habitual procedural
> >developers to grasp than simply to 'hack up' some working code.
>
> Not just for habitual proceduralists, but for everyone. OOP is
> inherently more difficult, period. That is its problem. For where its
> applicability can be of use in certain esoteric problem solving, for
> business applications it's mostly hopeless overkill.

Beware of assuming that all developers have your mindset. Many (including
me) find that the OO element of a language solves more issues than it
creates, allowing you to decide how much of your app is OO based, and how
much remains procedural.
Heavy use of OO constructs are 'hopeless overkill' only if you use it to
develop some minor utility to (for example) edit a single database table or
modify a config file, trying to force OO constructs on something that simply
does not need it.

> There is nothing
> complex about ordinary, everyday business practices. Folks have been
> running businesses for centuries. The basics don't change. The
> concepts of profit and loss, stocks and shares, buy and sell, product
> development, cost management, and all the other standard business
> practices do not change.

Which is why businesses manage quite happily with nothing more than an Excel
spreadsheet?
I suspect you are discussing businesses such as accountants, butchers,
news-agents, and funeral homes
Businesses such as banking, insurance, and anything that needs more than a
copy of MYOB to survive _are_ complex.

> What changes is that the old boys, often
> without any formal qualifications, hang up their Hollerith cards and
> die off, to be replaced by new, eager graduates fresh from academe who
> take their place, their heads full of theory and empty of experience.
> This is what business nowadays has to utilise. Hardly surprising, when
> said graduates are fed on a diet of OOP and nothing but OOP, that they
> will not want to employ OOP as the one hammer to crack any nut when
> they are finally let loose upon an innocent public which still can't
> fathom how to set up the VCR.

Yep, and many of these people fall flat on their faces. In what way does
this invalidate OOP? It sounds to me to be more of an education issue,
explaining to students _how_ and _when_ OO concepts should be applied. You
clearly recognise when it should _not_ be applied, but you extend that to
100% of situations

Cheers,
Jason