# What a way is more OOPer ?

I must to implement Quaternion and Complex numbers classes. I began so:

template <class T>
class Quaternion
{
public:
...
Quaternion(); // few kinds of Ctors
...
private:
T w,x,y,z; // w+xi+yj+zk;
};

I have 3 ways to continue:

1-st way:

template <class T>
class Complex1
{
public:
...
Complex1(); // few kinds of Ctors
...

pirvate:
Quarterion<T> q;  // I use the q as complex number
// and its y,z fields initialized by zero;
};

2-nd way:
template <class T>
class Complex2:public Quarterion<T>
{
public:
...
Complex2(T a, T b):Quarterion(a,b,0,0){}
// yet few needed Ctors
...
};

3-rd way:
template <class T>
class Complex3:private Quarterion<T>
{

How can I to declare here function from Quarterion class so that they should public (I don't want that user of    Complex3 class should be able to use function from Quarterion beside of function I'll permit for using)?
};

What way from these is prefer ?

Thank you.
LVL 1
###### Who is Participating?

x

Commented:
I think the Liskov Substitution Principle (also mentioned in the link yonat gave above), shows that at least public inheritance is probably the wrong answer in this case.

LSP is the principle of substitutability,  it states that for public inheritance you should be able to use (in this case) a Complex number *anywhere* you can use a Quaternion.

This is probably not the case - for a Complex number you require that the y & z fields are presumably always zero.  Therefore if any operation on Quaternion violates this condition, then inheritance is a bad choice.  e.g. if there is a public method on a Quaternion that changes the y or z fields, then public inheritance is the wrong choice.

Private inheritance *might* be the right answer, but only if either i) you need to access protected methods of the base class or ii) you need to override virtual methods of the base class.

As such, the right answer is most likely to be containment/aggregation (your 2nd way), although as yonat suggests, this very much depends on the details of what you are doing.
0

Commented:
This is known as the ellipse-circle dilemma (or the rectangle-square dilemma). The basic answer is that you should do what makes more sense in your context, and not necessarily reflect what mathematicians consider to be the true taxonomy.

0

Author Commented:
I implement it through aggregation, although before it I tried private inheritance, where I meet with next problem:
I've adjusted access control to member function which I need in Complex for example:

template <class T>
class Quaternion{
...
public: Quaternion<T> operator+ (const Quaternion<T> q);
...
};

template <class T>
class Complex:private Quaternion<T>{
...
using Quaternion<T>::operator+;
...
};

and in user code:

...
Comlpex c1(1,2),c2(3,4),c3;
c3=c1+c2;
cout << (c1+c2);
...

// of course I have comp. error. So, although I have access to op+ in Quaternion I cannot use it with Complex parameters !
I tried partialy solution as definition
operator Quaternion<T>(), but anyway returned value is Quaternion<T>  :(
0

Commented:
> cannot use it with Complex parameters !
> I tried partialy solution as definition

it just won't work as you have it, this kind of exposure of Quaternions methods is a bad idea... how will you deal with:

Quaternion c1;
Complex    c2, c3;
....
c3 = c1 + c2;

This is exactly one of the cases I described above... substitutability fails here.  (and by making Quaternions methods public, you are in effect implementing a kind of selective public inheritance).
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.