[quote name='Madhed' timestamp='1299060955' post='4780920']
Erm, nobody tried to shove his beliefs down your throat. All I see is simply a: "I think this is better, think about it" Yet you are the one who gets all jumpy about it.

Wasn't referring to how you handled things. You were fine. Ravyne said things like "You're wrong this is why" and Hodgman summarized my entire argument as "[color="#1c2837"]Science is wrong, biatches!" and stated, but I guess removed, his opinion that I've degenerated this thread into trolling by having an opinion. ^^

"[color="#1c2837"]You can't grantstand on "fighting the established order of things" without nodding to the fact that many of the "rigid" standards have already weathered generations of cynicism, scrutiny, and testing through application. You also have to accept that the answer to "questioning those before us" is sometimes "well, yes, they WERE right.""

[color="#1c2837"]Very true. They often are. But I just don't live my life blindly. I don't see the point in living life by the book without questioning it. But the matter at hand can't be tested XD That's why I stated that it's not science. There's no measurement for success. There's no performance increment to look at. If you can't test it, isn't it an opinion? If someone tells you that the sky is green what if they really see it as such? There's no way to prove them otherwise but by collective "opinion".
[/quote]

Let me add my own small opinion to this. Yes, people should just blindly follow a widespread practice in an industry until they understand why exactly it is there. In general, these practices are there because countless professionals, each with many years of practice, have tried out different methodologies, different paradigms and formed valuable opinions, a consensus. You can swim against the tide if you want, though you won't get anywhere fast.

Also take into account convention. When you are part of a team, it is to your advantage to follow common ways of thinking because that results in more efficient communication and thus faster, more painless work.

[quote name='Madhed' timestamp='1299060955' post='4780920']
"[color="#1C2837"]You can't grantstand on "fighting the established order of things" without nodding to the fact that many of the "rigid" standards have already weathered generations of cynicism, scrutiny, and testing through application. You also have to accept that the answer to "questioning those before us" is sometimes "well, yes, they WERE right.""

[color="#1C2837"]Very true. They often are. But I just don't live my life blindly. I don't see the point in living life by the book without questioning it. But the matter at hand can't be tested XD That's why I stated that it's not science. There's no measurement for success. There's no performance increment to look at. If you can't test it, isn't it an opinion? If someone tells you that the sky is green what if they really see it as such? There's no way to prove them otherwise but by collective "opinion".
[/quote]

It's one thing to question things, and honestly you are entirely within your right to say "Well, I know I'm violating established practice, but it hasn't blown up in my face yet, so I'm fine with it." however, composition vs. inheritance, and the appropriate use of such, is well established in the computer science community. As I stated earlier, LSP and SRP have been vetted by hundreds of smart people over the past 30-40 years -- you may not see the difference adhering to these principles make in small projects, but in large projects which change and have to be maintained and extended over time, you will rue the day you chose inheritance over composition when it was not warranted.

You charge that the benefit is immeasurable and therefore opinion -- false on both accounts. While hard numbers like performance or binary measurements like "well, did it work in the end" don't seem to indicate a difference, and "source code quality" might seem far too subjective to be a useful measure, I would argue that the latter is not as subjective as it seems, and indeed at least as useful a measure as the former.

Let us assume that there exists a group of very smart computer scientists, and let us assume that they have written a great deal of software, much of it medium or large-scale. Let us also assume that they have an academic and professional interest in developing the best methods possible, and that originating said methods is incentively (prestige, better jobs). Now let us assume that these people, having gotten together to share their experiences noticed certain patterns across their independently-developed projects. They talk about what works and where their individual solutions fall flat, and over time they co-develop a solution to a particular problem that seems to have the greatest benefit and the least amount of headache in aggregate. This is what a Design Pattern is (keeping in mind that a pattern is just an idea to be applied, not a thing to be applied.), this is what idioms are, this is what stands behind "theories" like LSP, SRP and innumerable others.

What you seem to insist on arguing, is that your one opinion, based on your own limited experience, should call into question the collective work of literally thousands of man-years of insight on these topics. If that's what you want to *do* then fine, go do so -- I'm confident enough in these assertions to say that, without question, your casting aside of these principles will one day make your programming life more difficult than it need be. But I would be remiss as a member of this community and as something of a computer scientist myself, if I did not counter such wild claims. You offered a solution that works, I offered one which "is better" -- and I can't point you to a chart or statistics, only to the collective experience of hundreds of minds greater than my own, or your own. If you want to take those odds on, so be it, but to recommend following suit is negligent.

I wouldn't think about the number of classes versus the size of the game. When I am designing games or applications I think about how to logically break things up into classes that makes sense. In the end, my solution may be 4x larger with all of the class definitions and extra curly braces and other crap but my design is a true object oriented approach and easily maintainable opposed to 1 UBER class that has everything in it.

When I wrote a pong clone I had the following;
-Abstract paddle class
-Enemy class extends paddle
-Player class extends paddle
-Ball class
-Wall class that were the outter boundaries for collision

Player and Enemy should be the subclass of some class if you want to extend to have more than 2 players so they can be stored in a player array or have variable numbers of ai and human players.

Thus why I said they should be subclasses only if they need to present a uniform interface to some client. My broader point is that in the context of Pong, there is no such client, so there is no need for a uniform interface. Were we instead designing 'Pong the MMO', we might have to revisit that distinction...

If I view the an enemy AI and his body (sprite) as one, who's to say I'm wrong in binding them via inheritance?

The Single Responsibility Principle should be your first clue. Wrapping up graphical representation with logical representation in a single class is only going to lead to trouble down the road.

What happens when you need an enemy AI without a sprite? An enemy sprite without an AI? The same AI with a non-sprite representation? The same sprite rendering attached to a different type of AI?