How to design such class

[gigal]

Currently, the class is defined as,

Class CarClass
{
EngineClass e;
SeatClass s[5];
CDPlayerClass cd;
....
};

In the future, a new member of class GPSClass type could be added for
example. EngineClass, SeatClass, and CDPlayerClass could change their
implementation of operations.

How to design CarClass?

Thank you very much!

 

[John Harrison]

Currently, the class is defined as,

Class CarClass
{
EngineClass e;
SeatClass s[5];
CDPlayerClass cd;
...
};

In the future, a new member of class GPSClass type could be added for
example. EngineClass, SeatClass, and CDPlayerClass could change their
implementation of operations.

How to design CarClass?

Thank you very much!

I don't see anything wrong with the design you have, what do you think is
wrong with it? It's pretty hard to why it should be any different given your
description.

I think the emphasis of the question is quite wrong, maybe you've
misunderstood what you've been asked. Obviously EngineClass etc. could
change in the future but it is not the responsibility of CarClass to use
EngineClass in some special way just in case it might change. That would not
make EngineClass very user friendly, and would mean extra work for every
class that used EngineClass. Instead it should be EngineClass that is
designed in such a way so that other classes can use it without worrying
about future changes to it implementation. This is a basic goal of object
orientated design.

john

 

[Chris Theis]

Currently, the class is defined as,

Class CarClass
{
EngineClass e;
SeatClass s[5];
CDPlayerClass cd;
...
};

In the future, a new member of class GPSClass type could be added for
example. EngineClass, SeatClass, and CDPlayerClass could change their
implementation of operations.

How to design CarClass?

That depends very much on what you want to achieve. In principle the example
you gave is the straight forward approach and there is nothing wrong with
that, however there are of course different ways. One might think for
example of introducing a vector of additional features which holds some
customer specific "extra equipment" like GPS, TV, mobile phone or whatever
which is not included in the standard version of the car.
Another way would be to use a decorator pattern, though I guess that might
be too much for a simple thing like this.

Thank you very much!

HTH
Chris

 

[Michiel Salters]

Currently, the class is defined as,

Class CarClass
{
EngineClass e;
SeatClass s[5];
CDPlayerClass cd;
...
};

In the future, a new member of class GPSClass type could be added for
example. EngineClass, SeatClass, and CDPlayerClass could change their
implementation of operations.

How to design CarClass?

Well, you did the correct thing by realizing that some things are more
likely to change than others, and you should indeed design for that. One
of the most important things to realize is what can change after
creation, and what's fixed. Of course, this is restricted to your
model. If you don't model recycling the steel in the doors for a
new engine, things are a lot easier.

Now, let's take your GPS class. Is that only added when the car is
built? Or can it be added later? That is an important distinction.
In the first case, you can create a new model car, with GPS. In
the latter case, you keep the single model but you add a mounting
point.

In C++ terms, the first solution is to create a class CarWithGPS,
the second solution is to add a GPS* to class Car. This pointer
would be == 0 until the GPS is mounted.

The second question is easier. Just keep the implementations
of these classes private, so that Car only relies on their
public interface.

Regards,
Michiel Salters

 

[Denis Remezov]

Currently, the class is defined as,

Class CarClass
{
EngineClass e;
SeatClass s[5];
CDPlayerClass cd;
...
};

In the future, a new member of class GPSClass type could be added for
example. EngineClass, SeatClass, and CDPlayerClass could change their
implementation of operations.

How to design CarClass?

Another thing: if CarClass gets even just moderately big and complex,
you may notice a number of big adavantages in arranging its parts into
hierarchies:

class CarClass {
Body b;
Mechanics m;
Conveneience c;
//...
};

class Mechanics {
Engine e;
Transmission t;
//...
};
class Convenience {
GPSClass gps;
CDPlayerClass cd;
//...
};

At a top level, each component is a Facade to its sub-components, and
so on recursively. Each facade provides a single interface to a higher-
level system; it hides the dependencies and implementation details of
its sub-components.
The "right" way to structure this depends on the aspect that you are
modelling (e.g. whether CarClass is used to build a functional model,
parts inventory, or an informational pamphlet).

Denis