Any help on this really, really appreciated.
Thanks,
Paul.
RE: Thinking OOP problem
Author
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.
Any help on this really, really appreciated.
Thanks,
Paul.
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
Kuphryn
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)
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)
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?
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?
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
Car ferrari;
ferrari.engine.on();
ferrari.window.rollDown();
etc
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
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
