Hello, i''ve got a very ltitle problem i''m hoping someone can help me with. Let say i''ve got 3 classes ClassOne ClassTwo ClassThree Now ClassOne HAS A ClassTwo lets say ClassTwo also has a variablea m_iNumber and for the sake of argument everythign is public. now ClassThree wants to be able to set m_iNumber in ClassTwo to 4 but he doesn''t HAVE A ClassTwo he''s just something that happens to know something that ClassTwo will want to know, so he wants to PASS it to ClassTwo. But ClassThree doesn''t have any idea wher ClassTwo is... how do you guys solve this OOP problem? or is there a way i''m missing to avoid it. A practical example might be a controller function, he takes keyboard inputs and mouse inputs and decides what needs to be done in each case CGame would have a CController but CController would have to know where almost everything else is so that the user could interact with the game... - Newb Programmer: Geek++

Hmm, well perhaps you could make a method in Class3 that takes a pointer to a Class2 (and, therefore, gives access to the Class1). But it depends on what specifically is going on, this could be good or bad programming practice depending on what Class2, Class1, Class3, and the variable are used for.

Oh, I just saw your example.

In the controller case, don''t let the controller itself do any of the action. It shouldn''t be anyways: it''s a class that simply represents a controller and buttons being pushed.

Rather, have it store what button is being pushed (or has been, or something like that), and have cGame reference that variable and have cGame use that variable, along with collision detection or what-not, to determine if the button being pushed is a valid one to push, and to make the game react accordingly to the button.

In other words, cGame has a cController. cController has a variable "buttonpushed". cGame, in its'' "check for input" method, checks cController''s "buttonpushed" and uses its'' own code to determine if the game should respond to or ignore that button push.

Well my controller is my aplication.

Lets say I have a tank in my game
CTank
and it has a power to it''s shot and when you press the up key, you raise the shot power.

so CController polls all the keys and says "whoa he pushed up" and CController knows that he has to tell CTank to raise his power becase up was pressed, so he needs to call Tank.RaisePower()

Or something like that. But it cold be a command to be used on any object in the game, I think i''d be pretty messy to have controller having a pointer to every object....

- Newb Programmer: Geek++

Hehe,

This conversation has become rather "out of order" abut I see what you''re saying, alright. Sounds good to me.

in my other application I had a CScene make a list of images it wanted and where it wants them, but then I had to tell CGraphics to load the specific files for rendering later on.

I ended up having CScene make a vector array of the filenames it wanted, passed it back to CGame and then CGame sent the list to CGraphics for uploading.

Sound OOPish?

- Newb Programmer: Geek++

I think you''re focusing too much on the 3 letters OOP. One of the issues the OO paradigm is meant to address is the difficulty of designing of complex software. In a procedural or functional design, the code can become unwieldy and difficult to maintain. Object orientation helps in that it teaches us to think in terms of ''these objects do these things'' as opposed to thinking ''first do this then do that''. It''s a great concept once you get your head around it, but amazingly enough people seem to have a hard time with it. I think the trouble comes with trying to shoehorn procedural concepts into an OO design.

There are numerous design strategies and patterns that can help when designing software. Some are better when the moon is full on a tuesday, and others are good all the time. Most are just common sense and originate just from thinking in terms of objects. A great way to get into the habit is to look at everyday objects and think about how you would model them in code.

Take a TV, for example. You would obviously design a TV class to have methods for turning it on and off, controlling the volume and changing channels. That''s really all the functionality you need for a cheap black & white TV. You could extend that with a color TV class which provides methods for adjusting brightness, contrast, rgb levels, and other good stuff.

Taking that further, there could be multiple ways to send input to the TV. You might change the channel manually, use a remote control, or perhaps in this day and age use a laptop computer halfway around the world. Does the TV query all of the input sources to see if it should change channels? No it doesn''t. But neither do the input sources directly tell the TV what to do. Instead, theres a middleman that converts the input signal to the appropriate command. There are several ways to model this interaction in software. You could, for example, have a Controllable interface that all input sources can send input to. The TV can implement this interface (or perhaps a separate TV controller could) so that it doesn''t matter where the input comes from or where it''s going to. Once a Controllable receives input, it can translate it to the appropriate method call.

Some people say that such exercises are fruitless, and others swear by them. But I find that people who have trouble seeing the big picture tend to benefit greatly from modelling real-world objects as code. It helps get the mind adjusted to thinking in terms of objects, which is really important when you''re learning. If you get caught up in the details of what''s ''OOP'' and what''s not, you''ll tend to lose sight of the big picture. And the big picture is, what makes sense?