Re: A Car case

From:

Tim <Tian.Xiao.2007@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Wed, 22 Aug 2007 16:19:52 -0000

Message-ID:

<1187799592.371623.257150@q4g2000prc.googlegroups.com>

On Aug 21, 2:17 pm, hbrt <Hubert.Swietli...@gmail.com> wrote:

I have some questions on your implementation:
1. FordCar has to implement the virtual set.. functioins? Is it
repeating code?
2. In set engine to Ford, you need to check the engine type?
3. I am very interested you talking about the engine/transmission
hierarchy, considering these, it there any better design for the whole
system?
Thanks.

ad 1:
FordCar will reimplement set of virtual functions. As well as other
types (subclasses) of Car. Repeating code? It is not so obviously: if
you have ONLY class Car and class CarFord and you don't intend in the
near future to add other cars - then it is repeating code. But
consider this: you have multiple car-derived classes, all having the
same public API: setEngine() and setTransmission(). Using polimorphism
- it makes your code easier to maintanance. But - if all cars have the
same way to setEngine() - then don't make this function virtual, just
define its body in class Car - no code repetition :-)

ad 2:
It is hard question. It depends on the way you prepare the engine. If
you try make hierarchy for engines - and you use:
Car* carPointer = new FordCar();
carPointer->setEngine( new Engine(maybe_some_arguments) );
then you have to check wheter this particular Engine is for Ford only
(I assume this is your concern - never use engine for inpropriate car
producent) or not.
You can also move handlers for engine and transmission lower in car
hierarchy and define, that all FordCars should have FordEngine*
pointers. But then your virtual functions are not useful... I think,
that if problem is with vendor name, then maybe each car/engine/
transmission should have their own string with vendor name? Then
simply check these, while using polimorfic mechanism:
class Car
{
public:
virtual void setEngine( Engine* ) = 0;
string vendor;

};

class FordCar : public Car
{
public:
void setEngine( Engine* e) { if (e->vendor==this->vendor) continue;
else return; }

};

class Engine
{
string vendor;};

class FordEngine : public Engine
{

};

It's up to you what you need and how you do it :-) These are only some
proposals.

ad 3:
I know that using three (or more) pararell hierarchies is bad. It is
hard to handle everything so closly connected. Here you would have
Cars, Engines, Trasmissions, possibly more&more&more... If you add new
class, eg. NewGreatPolishCar, you also has to add its Engine class,
Transmission class etc. It's bad. Try to find other solution, maybe
Engine class (for example) doesn't use great advantages from
inheritance? Or maybe it is connected only to Car by itself, and the
only difference is in vendor name?

Still waiting for members discussion. Especially about this last
paragraph. How can one destroy so closely connected hierarchies?
Best regards,

hbrt

For the third concern, how about this:

A car hierarychy, A engine hierarchy, other parts hierarchy, and a
factory hierarchy

For the car hierarchy:

class Car is abstract and contains all the parts
class FordCar has a private constructor but frindly to FordFactory,
FordCar inherits parts and other method from class Car, thus it is
kind of blank.

class FordCar : public Car
{
friend class FordFactory;
private:
  FordCar();
};

For the factory hierarchy:

class Factory
{
public:
  virtual Car* BuildCar();
  virutal Engine* BuildEngine();
  ... //other parts
};

class FordFactory
{
public:
  virutal FordCar* BuildCar();
  virtual FordEngine* BuildEngine();
  ... //other parts
};