Jump to content
  • Advertisement

Archived

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

Sir_Spritely

RE: Thinking OOP problem

This topic is 5734 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have read numerous books and understand the syntax of how to program the classes and objects but I am having problems breaking things down into a suitable OOP approach. For example if I wanted to design a car, I would add:- Car Engine - On(), Off() Doors - Open(), Shut() Bonnet - Open(), Shut() Gear - Forward1(), Forward2(), Forward3(), Forward4(), Forward5(), Neutral(), Reverse() Brake - On(), Off() Clutch - On(), Off() Accelerator - On(), Off() Is this a suitable breakdown and is there a correct and incorrect answer to this or does it depend on how detailed you want it to be? I am trying to do an alarm system but I am having problems looking at it in terms of objects. All I have is, Alarm On() Of() Thats after reading lots of books and articles as well Any help on this really, really appreciated. Thanks, Paul.

Share this post


Link to post
Share on other sites
Advertisement
In your example, car is the base class. Everything else in the example should be inherited via protected or add instances of those objects in the car class. I recommend protected inheritance.

Kuphryn

Share this post


Link to post
Share on other sites
Objects are defined by thier behavior, and the behavior is only detectable through interactions with other objects.

What will the car ''do'' - what will it interact with?

There''s no need to have an engine object, unless you can change the engine - upgrades or something? If that''s the case, why would you upgrade? Whatever the reason, those are the methods.
(i.e. you''re not going to upgrade so that it can turn on).

I think I''d have a Car::Ignition(bool) method, not two aggregate On/Off ones. Likewise for the doors, Car::OpenDoors(bool)

Gear::ShiftTo(int gear) //-1 Reverse, 0 Neutral, etc...
Gear::UpShift(int n)
Gear::DownShift(int n)

Brake::Apply(float peddle_force) //how hard are they hitting the brakes? 0 force, 0 braking

The clutch is like the engine, what''s it do for the game? If you have a 3 peddle setup, then it needs to work like the brake
Clutch::Apply(float peddle_force). Otherwise, it''s like the engine, and should be assumed the avatar operates the clutch when shifting.

Accelerator::Apply(float peddle_force)

Car::ArmAlaram(bool)

Share this post


Link to post
Share on other sites
when you say ''for example if I wanted to design a car, I would add...'' you don''t talk about why you want to design a car and what you want it to achieve. those are very important questions.

start with the context, what problem your car is going to solve and define that as well as you can. otherwise how can you know if your design is providing a solution?

Share this post


Link to post
Share on other sites
What I would have is a car class with PUBLIC member objects like windows, engine, etc. so your calls would look like this:
Car ferrari;
ferrari.engine.on();
ferrari.window.rollDown();
etc

Share this post


Link to post
Share on other sites
quote:
Original post by kuphryn
In your example, car is the base class. Everything else in the example should be inherited via protected or add instances of those objects in the car class. I recommend protected inheritance.

/me shudders...



God puts an apple tree in the middle of the Garden of Eden and says, do what you like guys, oh, but don''t eat the apple. Surprise surprise, they eat it and he leaps out from behind a bush shouting "Gotcha." It wouldn''t have made any difference if they hadn''t eaten it... because if you''re dealing with somebody who has the sort of mentality which likes leaving hats on the pavement with bricks under them you know perfectly well they won''t give up. They''ll get you in the end. -- Douglas Adams

Share this post


Link to post
Share on other sites
quote:
Original post by kuphryn
I recommend protected inheritance.


[...]

quote:
Original post by fallenang3l
What I would have is a car class with PUBLIC member objects like windows, engine, etc. so your calls would look like this:
Car ferrari;
ferrari.engine.on();
ferrari.window.rollDown();
etc


These are two dreadful pieces of advice.

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
These are two dreadful pieces of advice.



Quit on contrary, the embedded public objects use access control themselves and if the user knows your assembling a bunch of parts (which a car is), it makes the interface much easier to understand. OOP is flexible and the idiom that "all public data members" are bad doesn''t quite fit everywhere.

Share this post


Link to post
Share on other sites
quote:

Quit on contrary, the embedded public objects use access control themselves and if the user knows your assembling a bunch of parts (which a car is), it makes the interface much easier to understand. OOP is flexible and the idiom that "all public data members" are bad doesn''t quite fit everywhere.



Nuhhuuh. Still bad. You might end up doing this:

ferrari.engine = lets_stupidly_assign_a_random_engine_by_accident();
//yes, okay, the name wouldn''t be that..

Now why is that bad? I can already hear you say, "but I want to assign a new car engine"...

Well for starters your not using pointers so you can''t have polymorphism (runtime at least) so you can''t swap in and out engine types.
Once you have pointers you have lifetime issues. Who destroys the engine? and if you have public access anyone could mess with it.
And not only that. What if only certain engines can fit into that car? You dont'' have any type of control.

I suggest in this case to use get() / set() methods, which return a interface Engine. Concrete engines are new''ed and passed to Set() which may to checking to ensure the engine fits. .


-----------------------------
Gamedev for learning.
libGDN for putting it all together.

Share this post


Link to post
Share on other sites
quote:
Original post by fallenang3l
Quit on contrary, the embedded public objects use access control themselves and if the user knows your assembling a bunch of parts (which a car is),

Why should users know anything about the internal structure of the objects they''re interacting with?
quote:

it makes the interface much easier to understand.

Compared to what?
quote:

OOP is flexible and the idiom that "all public data members" are bad doesn''t quite fit everywhere.

It fits here.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!