I just cant get OOP programming

[kempofighter]

OOP allows you to model components the same way that you think about them in a real world situation. How about a card game? What is a card? What is a deck? what is a hand? You model the building blocks the same way that you think of them in the real world. then they can be organized, copied, assigned, moved and so forth using generic algorithms that operate on the objects. So a card becomes the layout for a class type. The deck becomes an array of those card objects. A hand would be a smaller array of those card objects depending on the games. To deal you would simply move the card objects from the deck array to the hand arrays for each player. You might also have a discard pile as an array of discarded cards that builds up as you play the game. For me OOP is a way of organizing a program in terms of entities or building blocks that you can visualize in the real world. Each of these building blocks has a set of attributes that represents the kinds of data that would describe it as well as functions that would allow you to use it in some way.

[Incubbus]

I´m sorry, to ask this in here, but if I had to create multiple windows - for which i created another class.
And those windows (or - more precise - their procedure) shall call a function within my client class, to send some data to it...

How should I do it, so that the Window class does not know about the client class?...
I can only think about a member function pointer (::*) , or?...

[helios]

I can only think about a member function pointer

Then it would have to know about the client. A pointer to a member of A is not the same as a pointer to a member of B.
I can only think of: a) the client is derived from a class that the window knows about, or b) send the data to a dispatcher, which knows about all classes derived from... Notifiable? B) would pretty much be an Observer pattern.

[Incubbus]

Ok... thank You:)...

(But if I intend to use option a)... wouldn´t I have to make the window class superior to Client in the hierachy?)...

[helios]

(But if I intend to use option a)... wouldn´t I have to make the window class superior to Client in the hierachy?)...

I don't see why.

[Incubbus]

That does not make sense to me... Because, the window procedure needs to call a function from "sup class" - which delegates the work to the client - , the window procedure could also call the required function from client directy?!

_{If the window class is aware of an client´s base class (Let´s call it "sup class"; why don´t make the window class aware of the client class directly?...}

(Maybe I did missunderstand You, but I dont realize it, at the moment)...

helios wrote:

[...]a) the client is derived from a class that the window knows about [...]

Wouldnt this be done through an reference or an pointer to that class (or a function pointer to the function)`?


Exactly, what I want to try is:

1. The client owns an window manager, which - in turn - wraps the access to the single windows (window class)
2. The client can change the text in a specific window by using the window manager
3. The Window class needs to deliver User Input to the Client, wich delegates the handling of those to the adequate Manager

[helios]

If it's to handle user input and/or events, then you should definitely go with b). The Observer pattern is practically made for that.
Although I think your flow of information is messed up. Instead of trickling downwards as it should, it's kinda moving sideways. It should be the manager who gets user input and then queues it for lower classes to read it.

[S6k9GNh0]

class Paddle
{
   Paddle();
   int MoveUp(int);
   int MoveDown(int);
};

class Ball
{
  Ball();
};

Just from these two classes, one can easily see that we have a game of Pong or something that consists of a Ball and Paddle. With C, we can do something like:

void MovePaddleDown(int);
void MovePaddleUp(int);

void InitializeBall();
void InitializePaddle();

...which is still just as evident. But with the objects, we can group them together which helps us maintain problems, create better management, etc.

But in reality, it is nothing but preference.