RE: Thinking OOP problem

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

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)

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?

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

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.

quote:

---

Original post by risingdragon3
I suggest in this case to use get() / set() methods, which return a interface Engine.

---

I don''t regard that as good general advice either. The problem is twofold.

Firstly, ask yourself "why do we make data private in the first place?" Lots of accessors and mutators in a design can cause the same problems that public data causes. They reveal the internal structure of the class and allow clients to rely on that structure. Also, they are symptomatic of "mechanistic" design, where you are allowing the solution domain to drive and are ending up with interfaces semantically far removed from the problem domain, which is what you are *supposed* to be modelling after all. Don''t let the tail wag the dog - create interfaces based on the "business rules" that the class models.

Secondly, you''re recommending direct violation of the Law of Demeter, which I recommend folks try Googling for. Again, violating LoD makes a design rely on internal structure of classes - this time the composition of classes is revealed to the outside world.

The upshot of both of these problems is that you create yourself a design which is hard to change, where change is the only certainty of s/w development.

Okay...

Now I am seriously confused

Anyone know where I can view an example project for modeling a real world problem such as a Home burglar alarm, a heating system or something along those lines from start to finish.

Like writing the actual description of what you want everything to do right through to the actual Java or C++ code?

That is all I am trying achieve.

By the way thanks for the feedback so far, it has been helpful, a bit confusing as well

Paul.