Andrew,
Not a problem at all. I know that some of us (especially me) come off
rather coarse sometimes. But remember, its hard to express emotion on here
too.. I wasn't upset with you, was just like jokingly thinking, what on
earth are you talking about.
Aw crap, my bad.
I meant to say "In fact, *SOMETIMES* it's the wrong thing to do."
This is true...
(NOTE: I must have looked like a complete idiot, instead of the partial
idiot that I am.)
Anyway, please don't tell me you think inheritance is right ALL the time.
By no means is inheritance correct at all times. Appleman covers this topic
many times in his books (I like Dan, he's a good author), and in fact it can
be dangerous to use it if you don't know how/why your using inheritance.
A lot of people use it because it's the "IN" thing in programming (if there
is such a thing) and apparently if you use inheritance it makes you a better
programmer. Yes and no. Yes, if you can explain WHY you used inheritance.
What should I do when I want my Moose and Pig classes to have Flatulate
methods, add that to my BurperDefecaterAndUrinator class? But wait, my
Jabberwocky class also inherits from BurperDefecaterAndUrinator (because it
LOVES to do those things!), but due to a cruel evolutionary twist can not
generate flatulence. Now what?
And you bring up an excellent point right there. What to do? Humans are
interesting creatures (sometimes amazes me how we built these amazing
machines) because we tend to try to simplify things based on
repition/previous results. i.e. take your going to the bathroom idea, do
you think about having to get up, then walk x steps, lift toilet seat (if
your a man... and married...) and THEN do your business? Nope... we just
want to make it as easy as possible and don't really think about it. Now,
if computers could do this it would be great, and they can but because of
programmers. =)
So, what is to say we cannot break it out first by intefaces. I.e.
IDefactor
:
efacate()
IUrinator
::Urinate()
IBurper
::Burp()
Now we could build a class that implements all three... or only a few...
in to a collection of base classes that our "animals"... (Ahh we can use
both types of inheritance, kinda sounds like ADO.NET doesn't it =) DataRow
which is abstract (mustinherit) is an implementation of IList, ITypedList,
and IBindingList...
So to answer your question, you can build a build a base type, but you don't
have to use that base type to do your cross reference calls (remember that
implementation gets pushed up through the heirarchy as well) so your base
class that implements IUrinator and then something inherits your base
class... that new class also inherits IUrinator, so we can directly cast to
IUrinator.. Thats if the only thing you care about is making your animal
urniate, not how... just the fact it does.
I'm just trying to get Craig to think about alternatives that might not have
such a "permanent" impact on his code/architecture.
Exactly... my whole point is (as many will agree) inheritance is a
wonderful thing, however, it does take careful planning and management (as
most software does). So your point is valid there, your explanation was a
little off to why though. =)
Take care,
CJ
P.S. This is a fun place to be, don't get discouraged by doing anything
wrong... Hell, if I had a nickle for everythign I ever said wrong.. I'd
have a ****load of nickles...
=)
)