Warnexus, yes I do understand at least that. I also understand how superclass can have children that will inherit all methods and properties (extending).

Taking this simplified theory to actual practice is where I'm having troubles.

For example, if I want to design a map system with enemies on it, I'll instantly think of making an array for the map coordinates along with an array that contains all game objects, etc. Unless forced, I will not naturally think in terms of 'objects' & 'classes' because, while I believe I understand the underlying theory, I'm having a rough time applying it in context and leveraging it efficiently.

One thing I'd like to do is to code pong in a non-procedural way for example, but I'm having a hard time architecturing my concepts in terms of classes and objects. I can code allright, but I can't think in terms of how it needs to be built if it is to be OOP.

Is it any clearer? (its hard to talk about things I only half grasp)

The point of a class is for re-using code which prevents duplicated code and allows for reusability of this class in other projects.

Before jumping ahead to code up the game, take paper and a pencil and think about the general things that are going to be in the game.

I don't think the major point of classes is really re-use; they're great for re-use of classes, but that's a truism. Often though, you have a pattern of accessing an already existing object and want to reuse that pattern, so you use a function. Functions aren't part of the generic "class" definition but have been added to Java's classes because they are so useful for re-use.

I would say that the point of classes is that their way of describing encapsulation is easy to understand and that their invariants are easy for the environments to enforce, making development more stable due to fewer variables.

it also helps to use a language that forces you to stay in OOP land such as Java and C#.

OOP well the way I have read about it. Code reuse is common practice. So even in C you got function libraries. Might be that code reuse is made lot easier with OOP.

But I think it more a way to handle large software solution more practical. With a highlevel of view by its objects. So devide it in manageable components wich are decoupled as much possible. with it software solution becomes easier manageable and extensible. Also it seams you could do it the right way but also wrong. I suppose there is some skills involved to choose your classes right and depend also on the task at hand. So doing the OOAD right needs also some experience.

C++ Got to much pitfalls so Java or C# seams a good start on learning OOP

You might also try Object Mentor's pdf's, which give an excellent overview of some of the principles of OO design.

Yes, it was my next 'go-to' as it was part of the article's bibliography!

Thanks for referencing it regardless.

Also, I have to go with Dart for now, but I'll try to apply what I've read about encapsulation, abstraction, inheritance and polymorphism (I assume a lot of this comes with practice anyway). At least I have some ground theory to work from, so its better than learning by mimicking other people's code to achieve OOP results.

Thanks all!