Re: OOP Question
'enry,
> I wasn't trying to argue, I was just trying to help you clarify things.
I know! I'm of the same spirit. An increase in knowledge is good far beyond
the stature of "rightness." I'm of the opinion that this is a mind-expanding
exercise that does little, if any, harm...
> If you want to know my true personal opinion, it is an extremely relevant
> and pointed argument against OOP, which OOP itself creates, that issues of
> this sort arise and steal hours of people's thinking time when
> they could be doing more meaningful design or implementation work.
I have had that thought pop into my head, as well. I don't think it's an
argument against OOP, I think it's simply an argument against simplicity. I
also believe that OOP allows one to leverage those hours spent. Once we have
defined the object, it is usable over and over again, ad infinitum, ad
nauseum, Nike ad museum.
> Maybe (just maybe) AFTER I get the whole thing working via procedural
> programming, I can then intelligently REdesign something like this,
> assigning the responsibility for carrying particular bits of data and
> initiating particular actions to certain classes of objects.
The procedural approach, then: explain it for a game such as chess. You loop
through various sub-procedures, such as "get_moves," "draw_board,"
"determine_winner_if_any," etc...
> So what performs the action? The "program" object, which OOP
> really tries to exclude and pretend does not exist...
This "program" object I have discovered and named, "Game_Object." It exists,
regardless of whether or not OOP wants to exclude or deny (hey, just like
the Creator God of the universe! But I digress...). In fact, without the
context of this "Game_Object," I don't see any way to truly model the game I
want to create! Sure, we can let the piece carry its current position, but
if we want to model real life, I think we have to let the Game_Object do it,
because IT is the object that knows the rules. Not even the playfield can
hold the rules, as was demonstrated with my previous illustration of the
bishop's changing role on a chessboard. The playfield and the pieces are
simply pawns in the Game_Object's universe.
> You refer to the "god" object. Same as the program object, or the
> omniscient programmer as shey embody sheirself in the code (where
> shey, sheirself are gender-neutral singular pronouns of my own
> invention).
For a second I thought it was a speech-impediment made manifest via
keyboard. Now I'm simply left wishing that's really what it was, instead of
political correctness. Ah, well. I'm male so what do I know? 
> Sorry, but OOP is a godless approach to programming,
> where every data structure becomes a
> demigod, but a god is unnecessary;
But didn't you state your belief in the god_object, despite OOP's denial
thereof? The god, it seems, is necessary! How else does OOP programming
work? Maybe I just don't understand.
> to trivialize what you're doing, my POV is more aloof, and I'm more
> interested in taking an abstract view of the whole ball of wax.
I'm actually as interested in the forest as I am in this tree. I'm doing
this as much for the benefit of the big picture as I am for the pixel. My
contemplation here will have its reward in my future as well as yours and EU
OOP.
I like the abstract view because it is interesting and stimulating... moreso
simply because I am NEW to it. I'm sure there are old-hat OOP guys 'n' gals
out there who are yawning at this whole thing (or non-OOPers like jiri who
are yawning as well). I appreciate their willingness to let this run its
course!
> Saying that, to me a playfield should be a "stupid" thing - in the sense
> that, what does the playfield neeed to know, or be responsible for?
Well, unfortunately, the pieces are stupid too. So, we've realized our need
for the Game_Object, to control these stupid objects, right?
> If I want to know the position of the Earth at 4:04 AM
> on November 25, 2000, I am more inclined to formulate my
> query as earth.position("2000:11:25:04:04") than as
> space.position("earth", "2000:11:25:04:04"). I just don't
> see any sense in asking space where each object is in relation to it.
For simplicity's sake, you are inclined to do so... However, whereas you are
desiring procedural simplicity, I am desiring an accurate OOP model, and
despite the fact that the space object would be one humongous object, my
viewpoint is that it should retain the position of the stupid objects that
reside within it.
> It's simpler (note, one less argument, since
> position in *space* is the only position that's meaningful) to
> ask each body where it is.
But, IMO, it's an inaccurate model, and therefore I choose to disregard it.
> So do I want space to "know" where a potentially infinite
> number of bodies are at all times, or do I want each body to know its own
> whereabouts, velocity, and trajectory? I think, the latter.
I think the use of "potentially infinite" constrains your thinking.
Disregard any current limitations of data storage... If you were going to
model it all, would the position of an object be obtained from the space
object, or would it be gotten from the floating rock?
/huh?start
An object can know, however, its velocity in relation to its facing... It
would not know its facing, but it would know if it was "moving to its left,"
"moving backward," etc., would it not? Therefore, trajectory could be a
property of the object. Wait. No. Then you have the playfield querying the
planet object for its position.
/huh?end
> Of course, the
> whole situation is a lot less complicated with game pieces on a playfield,
> my analogy is imperfect, and we're free to treat bodies in space and game
> pieces on a playfield completely differently.
Well, we simply add gravity rules to the "game_object" and, WHAMMO, the game
of space, where the (relevant for us) playfield is our solar system and the
pieces... well... anyway.
> Maybe Earth has one position in
> space, and a completely different
> position in hyperspace.
Imagine further defining the planet class, to include the name of the solar
system within which the planet resides, its neighbors, etc. Now you could
have
system("sol").planet("earth").neighbor(1) = "Venus" AND
system("sol").planet("venus").neighbor(1) = "Earth",
which is, in my book, a duplication of data and therefore BAD! IOW, you've
got the same data represented multiple times. Isn't that considered a "bad
thing" in database design/programming?
Remove that property from the planet and give it to, say, the system object,
and now earth and venus can ask, who are my neighbors, and get that data
from the same data source.
I don't think I did my OOP representation very well up there, but hopefully
you understand my intent. If any OOP-guru can shed light on the above, and
my horrific mangling of it all, please chime in.
> where I am back to the simplicity of a single
> argument and the sense of rightness that (to me)
> goes along with that simplicity.
Just to clarify, are you deriving your sense of rightness from the
simplicity, disregarding the accuracy of the model, or do you believe your
model is accurate, as well?
We don't disagree that the model you present is simpler- I think we disagree
on whether that model is accurate.
And we both question whether it matters.
-ck (my nickname, which my third-grade teacher saw fit to give me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
|
Not Categorized, Please Help
|
|
