If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

[RESOLVED] Design advice required

I am trying to design and implement a program that consists of two classes. The Base class A is purely for supporting class B. I do not want to be able to create an object of class A. When object B is created it inherits from class A.

Re: Design advice required

Make A an abstract base class. There presumably will be some virtual function for which an implementation in A wouldn't make sense: make that pure virtual. If really no such virtual function is available, then make the destructor pure virtual, but you still need to implement it.

Re: Design advice required

Thanks Laserlight. I have looked at abstract classes and it does not really fit into my design. I have not got any virtual functions and don't understand them at this time. I have decided to look again at my project and redesign it. Going to keep my two classes simple for now until I understand more. Thanks again.

Re: Design advice required

Originally Posted by Gerald Bates

I have not got any virtual functions and don't understand them at this time.

In that case, B probably should not inherit from A, and if it does inherit, it should use private inheritance. My guess is that you should have an object of class A as a member variable of B (composition) instead of using inheritance. A can either be defined in a namespace named detail (to indicate by convention that it is implementation detail), or perhaps as a private nested class of B.

Re: Design advice required

Re: Design advice required

I never considered composition in this case, but now I think it makes more sense. The trouble I have at times is understanding the 3 relationships my book refers too; "Has-A", "Is-A" and "Knows-A". I guess in time I will be better at judging how to best implement a solution! I will use composition and see how I get on.

Don't understand why I would make a constructor private? Never done that?

Again, thanks for all your help. Will finish the basics of both classes and see if this works.

Re: Design advice required

Originally Posted by Gerald Bates

I never considered composition in this case, but now I think it makes more sense. The trouble I have at times is understanding the 3 relationships my book refers too; "Has-A", "Is-A" and "Knows-A". I guess in time I will be better at judging how to best implement a solution! I will use composition and see how I get on.

Don't understand why I would make a constructor private? Never done that?

Again, thanks for all your help. Will finish the basics of both classes and see if this works.

Making the constructor private will prevent you from creating an instance of that object, which is what you said you wanted to do. Pure virtual functions are the normal way to go about it.

"Is a" is the requirement for inheritance. For example a car is a vehicle, so it would usually make sense for a car class to inherit from a vehicle class.

On the other hand, a car "has a" wheel, but it's not a wheel, so it wouldn't make sense to derive wheel from car.

Re: Design advice required

i'd like to make point of stating that the "is a" relation is based on the technical implementation/design and NOT on the fysical / real life situation.

You often see introductory courses on object oriented design use shapes as a base class with more specialised shapes (square, circle, ...) as derived classes. They start nicely, but invariably fumble things up along the way, and when things get interesting/messy, they stop elaborating on the example entirely.

The "is a" in the concept of object oriented design is really about "the derived class has at least all the base properties, plus maybe something more"
If it doesn't have ALL the same base properties, then deriving is inappropriate, even though everyone around you will tell you "but x IS A y".

As an example, take an ellipse. IN the real world a circle is a special form of an ellipse (a circle is an ellipse). so it might be tempting try and derive your circle class from your elipse class.

Code:

class circle : public ellipse
{
};

This will get you into trouble somewhere down the road, because a circle doesn't share all the properties of an ellipse. an ellipse can have a different width and hight, while a circle cannot.

If you take your circle pointer, and cast it to it's ellipse pointer, then do pElipsifiedCircle->SetSize(2,3);
Do you suddenly have a circle that is 2 wide and 3 high ? wait ? what ? I now have an assymetrical circle ? Is the world ending ?

So... using GCDEF's example... is a car a vehicle and can I derive my car class from the vehicle class.
Well... that depends entirely on how you defined your vehicle class
suppose you create a vehicle class, and then make a Drive() memberfunction.
Now... a boat is a vehicle too... but what's going to happen if you do MyExpensivePleasureYacht->Drive() ?

How you define your base classes effects what you can derive from it. And what you can derive from it may or may not match real world scenario's.

Re: Design advice required

Originally Posted by GCDEF

Making your base class constructor private should do it too.

Not protected? Wouldn't making the constructor (more pecisely: all constructors, in case there's more than one) private effectively seal the class (i.e. make deriving from the class impossible at all)?

I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.