Inheritence question

[jared11]

Hi,

I began studying Inheritence and would like to ask a basic design question.

I want to create a base class shape that will have the following methods:

1. resize

2. move

These 2 methods will be virtual, and its Dervied classes: Rectangle, Circle, etc,

will override these methods and will implement them each on its own.

My question is:

how would the Base Class Shape should implement these 2 methods?

Should they be left empty in the Base Class Shape?

[kbw]

The base class wouldn't implement resize/move. They'd be defined as pure virtual. The language will enforce that Rectangle, Circle provide implementations.

It's conventional to think of BaseShape as an interface. That is, it defines methods that all derived classes will implement, but itself doesn't implement anything.

[mutexe]

see the last section of:http://www.tutorialspoint.com/cplusplus/cpp_polymorphism.htm

he uses his area() method as an example.

[jared11]

mutexe, kbw

Thank you very much!

I have additional question please.

How should the Rectangle and Triangle set their Position? (I thought to define Position as Center, that way it applies to many forms)

Should the Base Class provide setPosition(int x, int y, int z) Method?

The thing is that setPosition should be public and not protected, as the user may want to change the position of the Rectangle as well.

So the Base should provide Public setPosition, and not Protected setPosition?

Thank you.

[mutexe]

How should the Rectangle and Triangle set their Position?

i guess that's up to you dude :)

if your talking 2d objects (rectangle, triangle etc), not sure why you'd want a z coordinate on your setPosition() method.

The thing is that setPosition should be public and not protected, as the user may want to change the position of the Rectangle as well.

regarding setPosition: do you want this to do different things depending on the shape? if yes, all derived classes need a (protected?) setPosition() in the same was as your resize and move methods. if have one impl in your shape class.

[LB]

Position is something that should be handled by the base class, actually, and is one of my arguments against Java-style interfaces. Deriving classes should not be able to change the behavior of setting and getting the position.

[jared11]

hi mutexe

Thank a lot!

regarding setPosition: do you want this to do different things depending on the shape? if yes, all derived classes need a (protected?) setPosition() in the same was as your resize and move methods. if have one impl in your shape class.

I think I got you.

You say that if I want only derived-classes, as Rectangle, Triangle, to be able to set their position, then the

setPosition

method should be

protected in Base Class Shape

and

Public in Derived-Classes as Rectangle, Triangle

, right?

[MikeyBoy]

If the method is protected in Shape, then if you have a pointer to a Shape (because you're using polymorphism), then other code won't be able to call setPosition().

Is that what you want?

[mutexe]

if you have a protected method in your base class i'm not sure you'd be able to polymorphically call it in your main. i think :)


e.g.

int main( )
{
   Shape *shape;
   Rectangle rec(10,7);
   Triangle  tri(10,5);

   // store the address of Rectangle
   shape = &rec;
   // call rectangle area.
   shape->setPosition();  //  <- compile time error here
   ....
   ..... 
}

i.e. make it public. Although i'm hoping someone more knowledgeable than me (which is most people) could expand or correct me.

[LB]

Normally, non-polymorphic "forwarder" functions are public and the polymorphic virtual functions are private (or protected if they should be able to be called without the forwarder from the deriving classes).

[Cubbi]

A link with some detail on the interface separation that LB mentioned: http://www.gotw.ca/publications/mill18.htm

[jared11]

Hi Cubbi, LB, Mutexe,

Thank you very much! lerand a lot!


I have additional design question please regarding protected.

Why not moving all the Private Data members / Private methods of the Base Class into Protected?

I mean, why is it better to put the Private Data members / Private methods of the Base in Private, and provide methods to get / set the Data Members in Protected?

Thanks a lot!

[LB]

I should ask you the same question about why not to make everything public - the answer is the same.

[jared11]

Hi L B

Thank you.

As I studied, the Encapsulation of OO is to not expose the implementation details (e.g. data members) to the User.

However, The Class's Implementation (Both Base Class and Derived Class) is not part of the User space, but part of the Developer Space.

Therefore, why not letting the Derived Classes' developer to have direct access to the data members of the Derived Classes? (while keeping the user out of reach of these data members)

[LB]

You misunderstand - the goal of encapsulation is not to hide implementation details from the user or developer - the goal is to hide implementation details from other code. If code A does not know about code B, then code B should not know how code A is implemented internally and should only use code A's provided interface.

So, a deriving class is considered other code, and therefore should not know about the implementation details of its parent class.

The logical reason? To avoid code duplication. All code that works on a set of data should be grouped together (e.g. in a class) so that ways to access and manipulate that data exist all in one place and without duplication.

When you allow any other code to handle implementation details, you are duplicating existing code (which is bad) and you are doing it away from the existing code (also bad).

It doesn't matter whether you are a user, developer, or deriving class - you should always keep implementation details hidden.

And in case I didn't make it clear enough, protected data members should be considered part of a class' public interface - the only reason to make them protected instead of public is to indicate to the person writing the code "this is meant to be used only by the deriving class and not just arbitrary code".

[jared11]

Hi L B Thank you very much!

You made it awesomely clear :)