Passing Parameters

[Gianni Mariani]

Because it's incorrect use of inheritance from all accepted standards of OO
design. Your relationship is most definitely not IS-A.

Bogus. Since we don't have any design goals your comments are nonsense.

G

 

[jeffc]

That aside, there is nothing wrong with the model of the game. Dice is a
game by itself, any property of Dice is also a property of a Craps game.

You are using the word differently than anyone else here, and how any
reasonable person would understand it in this context. For example, what is
basketball? Basketball is a game. It is also a round orange ball. If I
say "throw the basketball through the hoop", then we know the meaning is
"round orange ball". If I say "let's play basketball", then we know the
meaning is "game". From the context of the original question, Sonia was
rolling dice, therefore dice meant white squares, not the game of dice. To
distinguish them, you'd have to have a class called DiceGame or GameOfDice.

But how does one now manage LoadedCrapsGame ? A loaded dice will have
methods for managing how to "load" the game. I suspect that the same
interface to load dice could be used to load the game.

Again you are twisting language badly and confusingly. No one would refer
to a Loaded Craps Game. You could have loaded dice, which are a special
kind of dice (LoadedDice IS-A Dice, with different behavior). Loading a
game has nothing at all to do with this meaning.

 

[jeffc]

That's nice. What exactly are these fundamental religions do you
proscribe to ?

I have developed my own ideas because the "fundamentals" I think you
allude to do not allways make sense when applied to the real world.

My goal is to make it so that building software is easier. One of the
tools is inheritance. If "easier" (huge overloaded term warning)
implies inheritance then we're done, inheritance it is.

The IS-A and CONTAINS-A giudelines are just that, guidelines. It's not
a law of physics.

You're backtracking, and badly. You said, "Craps is a game of dice. It's
100% obvious to me that this is a IS-A relationship." That is plain wrong,
and not many people here will sit silently while you give that sort of
advice. If you want to IGNORE clearly defined OO concepts, that's fine, but
don't try and advise someone on something wrong. If your goal is to make
building software easier, and you use inheritance when you should have used
composition, then you have made your software very confusing and difficult
to maintain. Again, no one here will concur no matter how hip you try to
sound.

 

[jeffc]

Clear ? Great, what are you trying to model ?

Since we have NO idea what is being modelled, your clarity perplexes me.

We are modeling the relationship between a car and an engine. This is clear
to any 8 year old, if not you.

 

[Gianni Mariani]

You are using the word differently than anyone else here, and how any
reasonable person would understand it in this context. For example, what is
basketball? Basketball is a game. It is also a round orange ball. If I
say "throw the basketball through the hoop", then we know the meaning is
"round orange ball". If I say "let's play basketball", then we know the
meaning is "game". From the context of the original question, Sonia was
rolling dice, therefore dice meant white squares, not the game of dice. To
distinguish them, you'd have to have a class called DiceGame or GameOfDice.

I don't see any modelling of a cube with little white dots anywhere in
this thread. What are you talking about ?

Again you are twisting language badly and confusingly. No one would refer
to a Loaded Craps Game.

Why not ? I just did ? Am I not a person ? Last time I checked I was.
You're making me feel like chopped liver with comments like these !

You could have loaded dice, which are a special

kind of dice (LoadedDice IS-A Dice, with different behavior). Loading a
game has nothing at all to do with this meaning.

Maybe I'm not twisting at all. Maybe that IS my perspective. Take a
few moments to look at it from my point of view. You seem to have
grasped the concepts rather easily since you can argue them so well.
Hence, from a perspective of communication of my ideas, you seem to have
grasped them rather quickly, yet you seem to argue more from a
perspective of dislike rather than anything else. My suggestion for
you: Get over it. Programs are an ABSTRACTION. Anything that I write
that models the way I want to model it is correct. I'm not going to
subscribe to a "my god is better that your god" kind of argument.

When designing software, you need to enable any abstraction that makes
it easier to create your software. Sometimes these model physical
concepts nicely and sometimes they don't, it really has no bearing on
the result. There are many paths to get to the top of the proverbial
mountain, whatever works for you is best for you.

 

[Gianni Mariani]

We are modeling the relationship between a car and an engine. This is clear
to any 8 year old, if not you.

Oh really !

Vibration ?
Noise ?
Energy ?
Power ?
Shape ?
Handling ?
Manufacture ?
Simulation ?
Game piece ?
Consituency ?
Decay ?
Acceleration ?
Fuel economy ?

I'm sure there are more things we can model that I can't think of right
now. Some of these make sense to use inheritance, some do not.

Any 8 year old would know that !

 

[Gianni Mariani]

You're backtracking, and badly. You said, "Craps is a game of dice. It's
100% obvious to me that this is a IS-A relationship."

And ? That still makes sense to me.

That is plain wrong,

and not many people here will sit silently while you give that sort of
advice. If you want to IGNORE clearly defined OO concepts, that's fine, but
don't try and advise someone on something wrong.

Explain what is "wrong" without spouting religion.


If your goal is to make

building software easier, and you use inheritance when you should have used
composition, then you have made your software very confusing and difficult
to maintain.

How do you know I "should have" done anything ?

 

[jeffc]

GameOfDice.

I don't see any modelling of a cube with little white dots anywhere in
this thread. What are you talking about ?

Sonia had a function called rollDice(). The Dice being referred to is the
objects - the white cubes. Not the game of Dice. Two completely different
things.

Why not ? I just did ? Am I not a person ? Last time I checked I was.
You're making me feel like chopped liver with comments like these !

Check again. You're a cyborg troll.

 

[jeffc]

If your goal is to make

How do you know I "should have" done anything ?

Have fun in your little dream world, Gianni.

 

[Gianni Mariani]

....

Check again. You're a cyborg troll.

And what would that make you ?

*PLONK*

 

[Gianni Mariani]

Have fun in your little dream world, Gianni.

This is an excellent example of how not to communicate.

Jeff, I am so sorry for you, you have demonstrated that the counter
argument you have is a most childish ad-homiem that even an SDC child
could come up with. (Apologies to all SDC children, most of them are
likely smarter than this.)

While you may have a valid argument, your skills in demonstrating your
position are demonstrably lacking. Please take the time to brush up on
you inter-personal skills before bothering to post again. I don't take
my time posting to c.l.c++ to harm anyone and to the contrary, all I try
to do is help. So, if my advice is misgiven, I sure would like to get
to the bottom of it so reduce the amount of inadvertent harm I may cause!

I have however, 20+ years experience and I can say that I have learned
many things the hard way.

Good luck, I hope you work through your inter-personal communication
problems soon.

Regards
G

 

[jeffc]

I have however, 20+ years experience and I can say that I have learned
many things the hard way.

That is to say, the wrong way. You're either trolling (and not very well),
or you got your feelings hurt because someone criticized your
misunderstanding of a fundamental OO principle, and now you're in a downward
spiral. The sting will go away in a few days, and you'll not recommend
anyone implement an HAS-A relationship with inheritance again, and all will
be fine.

 

[Gianni Mariani]

That is to say, the wrong way. You're either trolling (and not very well),
or you got your feelings hurt because someone criticized your
misunderstanding of a fundamental OO principle, and now you're in a downward
spiral.

That's wonderful - now explain yourself with facts and support it with
reason. All you have done is cite belief with no background, hardly
what I call "convincing" and more akin to religion, on top of that you
ice it off with an ad-homiem I'd expect from a 2 year-old bully. If you
hold your position with such conviction yet stoop to such dramatic lows
to justify yourself, you are hardly presenting a believable argument.

The sting will go away in a few days, and you'll not recommend

anyone implement an HAS-A relationship with inheritance again, and all will
be fine.

Another Jeffc(TM) content free totally useless ad hominem comment. Yep,
I'm certainly convinced now, so much more than I was a sentence ago -
NOT. You really need to learn how to argue more convincingly.

May I suggest that you make a CASE why under all circumstances what you
propose is wrong is actually wrong or simply stop posting. I have
better things to do than tutor you on how to construct an argument.

I actually think this may have been an interesting debate on when to use
inheritance and when not to use inheritance. It's a shame to have it end
this way.

 

[jeffc]

May I suggest that you make a CASE why under all circumstances what you
propose is wrong is actually wrong or simply stop posting. I have
better things to do than tutor you on how to construct an argument.

I actually think this may have been an interesting debate on when to use
inheritance and when not to use inheritance. It's a shame to have it end
this way.

It's funny you say that since you claim to have killfiled me hours ago.
Anyway, there is no "interesting debate" regarding obvious IS-A and HAS-A
relationships. The only one who doesn't understand that a car HAS-A engine
is you.

 

[Gianni Mariani]

It's funny you say that since you claim to have killfiled me hours ago.

You're right.

Let me fix that.

*PLONK*

 

[Peter van Merkerk]

If you disagree on the definition, than you will also disagree on
the

Oh really !

Vibration ?
Noise ?
Energy ?
Power ?
Shape ?
Handling ?
Manufacture ?
Simulation ?
Game piece ?
Consituency ?
Decay ?
Acceleration ?
Fuel economy ?

I'm sure there are more things we can model that I can't think of right
now.

Neither of those things changes the "has a" relationship between a car
and an engine. If those things would affect the inheritance relationship
between classes, the design would be very unstable when new requirements
need to be implemented. My experience is that a good design rarely needs
to be changed if at all. If the requirements change one might need to
add classes or members here and there, but it should not affect the
inheritance tree of existing classes.

Some of these make sense to use inheritance, some do not.

I wonder which OO Analysis & Design course you followed, your ideas are
radically different from what I have learned.

 

[jeffc]

You're right.

Let me fix that.

*PLONK*

Gianni, you really don't get it do you? I'm sure you've seen this done by
others, and you're trying to copy it. But it doesn't work that way. Just
writing *PLONK* in your message does not actually killfile me. There is no
little fairy that goes around checking for *PLONK* messages and then adding
that person to your killfile. Writing *PLONK* is really just Usenet slang
for *telling* someone the you're *going to* killfile them. You have to
actually go into your newsreader and use the utilities there to block any
messages from a particular sender. If you're having troubles using your
newsreader, please go to the newsgroup specific to your newsreader, or
newsreaders in general. This type of talk is really off topic here. You're
welcome.

 

[Gianni Mariani]

Neither of those things changes the "has a" relationship between a car
and an engine. If those things would affect the inheritance relationship
between classes, the design would be very unstable when new requirements
need to be implemented. My experience is that a good design rarely needs
to be changed if at all. If the requirements change one might need to
add classes or members here and there, but it should not affect the
inheritance tree of existing classes.

You make an excellent point regarding design which I have seen very few
engineers cite. New requirements should have little impact on a design.

The design quandary for software is that you don't allways know what
these features might be. The cost of maintaining a software product is
often directly related to this often overlooked factor.

More to the point, until you know the design requirements, you have NO
idea what you are designing for and what guesses you're making for these
unknown features.

Since the terms "Car" and "Engine" classes has little or no bearing to a
real physical car and engine, and you have no idea what features you are
optimizing for you should not prejudice your decision making by
assuming anything - including inheritance models.

Design Rule 1 - never artificially limit the utility of a class.

Arbitrary prejudice inevitably leeds to limited class utility and hence
poorer design.

You might be right, you may never need or want to subclass off an
"engine" class. The problem I have is that in a design process, the
decisions regarding class design appear after considering all design
requirements as well as the best guesses on new features you can come up
with. It is a flaw to make significant design decisions too early in
the process. Considering no design goals and stating that "car -has-a-
engine" is quite clearly a mistake because you limit the solution space
artificially.

One property of inheritance is that the base class interfaces are
available on the derived class and hence any change in the base class is
reflected on the derived class. When considering a design, this is the
predominant factor. The is-a vs has-a nonsense is simply a guideline to
help less experienced designers make a good decision. A more
experienced designer will seldom use the is-a vs has-a paradigm and will
instead optimize the design so that as new features are added, the
"right thing" happens with fewer chances of error. The "right thing"
often is somthing far more subjective since it depends on whose crystal
ball you are peering through.

 

[jeffc]

One property of inheritance is that the base class interfaces are
available on the derived class and hence any change in the base class is
reflected on the derived class. When considering a design, this is the
predominant factor. The is-a vs has-a nonsense is simply a guideline to
help less experienced designers make a good decision. A more
experienced designer will seldom use the is-a vs has-a paradigm and will
instead optimize the design so that as new features are added, the
"right thing" happens with fewer chances of error.

Oh brother. I hope some of those "less experienced designers" listening in
don't take this gibberish seriously. The best way to avoid problems as the
code expands is to get right the relationships from the beginning, e.g., to
use IS-A and HAS-A appropriately. I surely would hate to maintain some of
your code.

 

[llewelly]

It's funny you say that since you claim to have killfiled me hours ago.
Anyway, there is no "interesting debate" regarding obvious IS-A and HAS-A
relationships. The only one who doesn't understand that a car HAS-A engine
is you.

My car IS-A engine. To be more precise, it IS-A fire engine. There
are several reaons why this should be so:

(+) I have fewer traffic problems. Since it IS-A fire engine, my
car can drive over other cars with ease. Further more,
flashing lights grant me right of way in most areas of the
world.

(+) Loud horn. My car's horn can scare of rednecks, 4x4s, and
other small vehichles.

(+) Hook and Ladder. If someone gets out on limb during an
argument about inheritance, I can rescue them.

(+) Fire hoses. These are important when flamewars get out of
hand.

(+) Asbestos underwear. Why anyone dares discuss inheritance without
Asbestos underwear is beyond me. My fire engine comes with
several suits in a nice closet.

(+) EM equipment. I have observed that much blood is spilled in
certain threads. Emergency medical equipment is of obvious
utility.