Personally.... I think the problem most people have with OO is they get too caught up in the metaphor. Object.
Really you aren't talking about Objects in an object sense. It helps to think about it that way, but it isn't always going to happen that way. And it isn't always right to break everything down into many objects.
It is conceptual, and isn't always going to be real world objects.
the metaphor works great, until it doesn't. And most people that have trouble with OO get hung up where it doesn't work so great.
Lets take a simple example. An FPS.
One might be inclined to have a Character class that in composed of all kinds of sub classes like Eyes for seeing and Ears for sound. Then you extend that composite to both the player and the AI. However, in reality, this isn't going to be the best way to go about it, as the Eye is going to have Camera info for the player that the AI won't use, and other parts just for the AI that the player won't use.
What you'll likely end up with in reality is a Character class for all the aspects that will be shared, such as mobility and weapon choices and other things, then have a Camera class for all game cameras such as a 3rd person view, a cutscene or even the characters first person eyes.
You see, the metaphor breaks. the Player doesn't have a Camera. There is no rational Has-A relationship. However, functionally, in the game world, the player DOES have a Camera, because thats how the game works.
The whole point of OO is to allow for reuseable code. That Camera Class isn't going to do anything but camera related things. And so, if it is well written, you'll be able to port it as is into your next game.
but, unlike a procedural function. The camera class will be able to do things you couldn't do with a procedural system, and it will be faster. Example. Lets say you want a secondary 3D map view, or turrets, Or TV screens that have a view of another room. Since, in a well designed Camera class you will be able to grab essentially a screen capture view of what the camera sees, you'll be able to use it to create that view.
At least, if you designed it to do so, you could.
this is the power of OOP, reuseable code, easy to edit code, and since everything is designed seperate from eachother, if it can be understood by another class, it can be used by that class.
Camera becomes like a graphic, and could be queried for a screen capture like chunk of data just like it were a graphic. The fact that it grabs new data each time it is asked for a picture, should be irrelivent to the other classes. In fact... the Camera class has to ask the Player or TVSet class WHERE it is located to generate it's view. The camera just takes it's location and it's viewing angle, and any other properties it might have and pulls that from the 3D world...
This is just a simplistic example.
Really you aren't talking about Objects in an object sense. It helps to think about it that way, but it isn't always going to happen that way. And it isn't always right to break everything down into many objects.
It is conceptual, and isn't always going to be real world objects.
the metaphor works great, until it doesn't. And most people that have trouble with OO get hung up where it doesn't work so great.
Lets take a simple example. An FPS.
One might be inclined to have a Character class that in composed of all kinds of sub classes like Eyes for seeing and Ears for sound. Then you extend that composite to both the player and the AI. However, in reality, this isn't going to be the best way to go about it, as the Eye is going to have Camera info for the player that the AI won't use, and other parts just for the AI that the player won't use.
What you'll likely end up with in reality is a Character class for all the aspects that will be shared, such as mobility and weapon choices and other things, then have a Camera class for all game cameras such as a 3rd person view, a cutscene or even the characters first person eyes.
You see, the metaphor breaks. the Player doesn't have a Camera. There is no rational Has-A relationship. However, functionally, in the game world, the player DOES have a Camera, because thats how the game works.
The whole point of OO is to allow for reuseable code. That Camera Class isn't going to do anything but camera related things. And so, if it is well written, you'll be able to port it as is into your next game.
but, unlike a procedural function. The camera class will be able to do things you couldn't do with a procedural system, and it will be faster. Example. Lets say you want a secondary 3D map view, or turrets, Or TV screens that have a view of another room. Since, in a well designed Camera class you will be able to grab essentially a screen capture view of what the camera sees, you'll be able to use it to create that view.
At least, if you designed it to do so, you could.
this is the power of OOP, reuseable code, easy to edit code, and since everything is designed seperate from eachother, if it can be understood by another class, it can be used by that class.
Camera becomes like a graphic, and could be queried for a screen capture like chunk of data just like it were a graphic. The fact that it grabs new data each time it is asked for a picture, should be irrelivent to the other classes. In fact... the Camera class has to ask the Player or TVSet class WHERE it is located to generate it's view. The camera just takes it's location and it's viewing angle, and any other properties it might have and pulls that from the 3D world...
This is just a simplistic example.