Archived

This topic is now archived and is closed to further replies.

GeekPlusPlus

Got a question about OOP Structure.

Recommended Posts

GeekPlusPlus    124
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++

Share this post


Link to post
Share on other sites
VThornheart    246
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.

Share this post


Link to post
Share on other sites
VThornheart    246
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.

Share this post


Link to post
Share on other sites
GeekPlusPlus    124
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++

Share this post


Link to post
Share on other sites
GeekPlusPlus    124
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++

Share this post


Link to post
Share on other sites
Aldacron    4544
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?

Share this post


Link to post
Share on other sites
Zahlman    1682
Agreed. People get to talking about design X vs. design Y as "more or less ''object-oriented''", and from then on they don''t say anything meaningful. I''ve heard people describe a system as being more object-oriented on the basis that it contained more classes!

Ugh. Think instead in terms of the principles of oo - encapsulation (what can this thing logically do, and what does it contain/know about?), polymorphism (how much does the outside world need to know about this thing in order to use its interface? Can it pretend to be something else?) and delegation (can I make some other things do part of the work?). Solutions tend to come naturally.

Alternately - think from the perspective of the object that''s giving you the problem. If you want to talk to someone you don''t know, how might you go about that?

- you could do it passively, by letting the other person contact you. (i.e. invert the logical flow of your design.)
- you could arrange for a mutual third party to introduce you.
(i.e. ask ClassOne to provide a reference to its ClassTwo instance.)
- you could forward your messages through that third party instead, or through an answering machine or whatever. (i.e. send messages to ClassOne and arrange for it to delegate.)
- you could look the other person up in a phone book (registry).
Etc. etc. You need to pick what seems natural.

Share this post


Link to post
Share on other sites