What happens when you need an enemy AI without a sprite?

Is he invisible o.O

An enemy sprite without an AI?

Then I just draw the sprite : /

The same AI with a non-sprite representation?

Again, invisible?

The same sprite rendering attached to a different type of AI?

The sprite class I use has a pointer to the image associated with it that has been loaded into memory. It draws that image. It doesn't copy it. So... I'd just give it a copy of the sprite.

Were we instead designing 'Pong the MMO', we might have to revisit that distinction...

I was thinking 4 possible players (top, bottom, left, and right) who could be either AI, human controlled, or no player (wall). I'd say that's within the scope of a one dude pong clone.

Anyway, I concede that either way works and better-ness depends on how much is planned on being implemented.

By your logic, if i view a game as an object who is a singular object with attributes such as players and terrain and game mechanics and physics, then why not just make one God class that inherits everything from everybody and has no composition? Does that sound like fun to manage?

XD if you view it that way, then go ahead. Personally I think it's much more believable than an enemy "is" both himself (the AI) and his graphical representation (his body) than your extreme. Look, I'm even using "is". That's the problem with the principal. It's opinionated. If I say something IS something and you say something HAS something then people get in this big argument. Just forget the damn principal and program it logically. >.< If you see the player as BEING the paddle, use inheritance. If you see the player as HAVING the paddle, use composition. I don't care.

[quote name='No Style Guy' timestamp='1299095713' post='4781112']
By your logic, if i view a game as an object who is a singular object with attributes such as players and terrain and game mechanics and physics, then why not just make one God class that inherits everything from everybody and has no composition? Does that sound like fun to manage?

XD if you view it that way, then go ahead. Personally I think it's much more believable than an enemy "is" both himself (the AI) and his graphical representation (his body) than your extreme. Look, I'm even using "is". That's the problem with the principal. It's opinionated. If I say something IS something and you say something HAS something then people get in this big argument. Just forget the damn principal and program it logically. >.< If you see the player as BEING the paddle, use inheritance. If you see the player as HAVING the paddle, use composition. I don't care.
[/quote]

Precisely. My God class example used "is-a" because I was framing it to fit your view. I personally think it makes more sense that "A game has-a terrain, has-a player, has-a Physics system, etc" (as per my exmaple) or even "A player has-a Body (sprite) and has-a Brain (AI)" but you seem to think it should be "A player is-a Body and is-a Brain" (as per your example).

Regardless, I'll conceed that the is-a and has-a idiom can be subjective (or rather, both can work), so I wont argue that further.

The problem is that there are characteristics of each approach that are tangible, undeniable facts. If you have an inheritance tree where the current object has inherited attributes, either directly or indirectly, from, say, 10 different classes, the exact origin, purpose, and usage of those attributes is undeniably confusing. If the same current object was a composition of those classes, it would be (nearly) explicit where those attributes came from, what they affect, and why they're there.

I've lost count of the number of times where I've been trying to extend a class that seems to be modifying an undescriptive member variable (say, "count") which is not declared in the immediate class's header. I then backtrack through each of his multiple inherited base classes for somebody with a "count" member variable. If he had just had MyObject.baseclass.count, I would have had a lot less headaches.

Composition: easy maintainability, re-use, good cohesion and low coupling
Inheritance: less code, but poor {all of the above}

That is the basis for this argument, not opinions about how you view relationships of objects.

"Forgetting the principal" and "programming it logically" are at odds...the principal is both logical and time-tested. One can design for both inheritance and composition, the heart of the matter is that your opinion, this programming style that works for you on your own projects, is bad advice for someone wanting to follow good oo practices that scale well into any project.

[s]My original advice was to inherit the player class from the paddle class as I view the player as pretty much being the paddle in this instance. This debate then started when someone quoted oo principal as a means to debunk my method when in fact it followed the said principal. So how was it bad advice? And how does it not scale? If someone views something in a large scale project as being something, doesn't your principal teach that they should use inheritance?[/s]

I'm done, you're all right. There can be one and only one way to do things. I give up.

EDIT: "[color=#1C2837][size=2]from, say, 10 different classes" I wouldn't know I never use more than single inheritance

I'm done, you're all right. There can be one and only one way to do things. I give up.

EDIT: "[color="#1c2837"]from, say, 10 different classes" I wouldn't know I never use more than single inheritance

There are tons of ways to do things. There are much fewer ways to do things well. I could walk home every night by first flying to New York and then walking the couple hundred miles back, but that would be inefficient. There are however a couple routes home that are practically the same distance and walking time.

A good counter example to your thing would be having a player with a sprite and a physics object and AI. Does he inherit from sprite? Does he inherit from his physics object? Does he inherit from AI? Not all languages support multiple inheritance, and there's no reason a sprite should also be a physics object or AI or any other order.

Bad design can make sense in small games, but even on a one person game as complexity grows you will find these OOP principles come into play a lot more because eventually you will either be wasting tons of memory space/clock cycles or just won't be able to get your objects to work as desired.

As stated, I refuse to argue the matter further, why beat a dead horse? Do you really think it's a mature thing to do? Do you really believe it's mature to claim some one is acting the victim? Your hostility, name calling, and sarcasm have been completely unwarranted. Get off your high horse, recognize that I have made SOME valid points and A LOT of not so valid ones. The user above you succeeds the the fact that when deciding whether something IS-A or HAS-A is completely subjective (although usually obvious). There's no reason for you to be so obtuse. If you can't handle a mature debate, don't participate in one. It's easy to debate. Assert your opinion, provide evidence to support your opinion and provide couter points to the other's arguments. Difference of opinion != hostile intent. ^^