Vryjdfkk

Hopefully not too academic...

Let's say I need real and complex numbers in my SW library.

Based on is-a (or here) relationship, real number is a complex number, where b in imaginary part of complex number is simply 0.

On the other hand, my implementation would be, that child extends parent, so in parent RealNumber I'd have real part and child ComplexNumber would add imaginary art.

Also there is an opinion, that inheritance is evil.

I recall like yesterday, when I was learning OOP at university, my professor said, this is not a good example of inheritance as absolute value of those two is calculated differently (but for that we have method overloading/polymorfism, right?)...

My experience is, that we often use inheritance to solve DRY, as a result we have often artificial abstract classes in hierarchy (we often have problem to find names for as they do not represent objects from a real world).

Even if in a mathematical sense, a real number is a complex number, it is not a good idea to derive real from complex. It violates the Liskow Substitution Principle saying (among other things) that a derived class should not hide properties of a base class.

In this case a real number would have to hide the imaginary part of the complex number. It is clear that it makes no sense to store a hidden floating point number (imaginary part) even is you only need the real part.

This is basically the same issue as the rectangle/square example mentioned in a comment.

not a good example of inheritance as absolute value of those two is calculated differently

This isn't actually a compelling reason against all inheritance here, just the proposed class RealNumber <-> class ComplexNumber model.

You might reasonably define an interface Number, which both RealNumber and ComplexNumber would implement.

That might look like

interface Number

{

    Number Add(Number rhs);

    Number Subtract(Number rhs);

    // ... etc

}

But then you'd want to constrain the other Number parameters in these operations to be the same derived type as this, which you can get close to with

interface Number<T>

{

    Number<T> Add(Number<T> rhs);

    Number<T> Subtract(Number<T> rhs);

    // ... etc

}

Or instead you'd use a language that allowed structural polymorphism, instead of subtype polymorphism. For the specific case of numbers, you might only need the ability to overload arithmetic operators.

complex operator + (complex lhs, complex rhs);

complex operator - (complex lhs, complex rhs);

// ... etc



Number frobnicate<Number>(List<Number> foos, Number bar); // uses arithmetic operations

I would find it totally OK if complex number had a static factory method fromDouble(double) that would return a complex number with imaginary being zero, so a real number.

But I have trouble seeing why you would want to have a public inherited Real number class. Usually inheritance is used for these reasons (out of my head, correct me if missed some)

• extending the behaviour. Real numbers cannot do any extra operations complex number can't do, so no point in doing this.




• implementing abstract behaviour with a specific implementation. Since complex number should not be abstract this also does not apply.




• code reuse. If you just use the Complex Number you reuse 100% of the code.




• more specific/efficient/accurate implementation for a specific task. This could be applied here, real numbers could implement some functionalities faster. But then this subclass should be hidden behind the static fromDouble(double) and should not be known outside. This way it would not need to hide the imaginary part. For the outside there should only be complex numbers (which real numbers are). (This assumes the classes are immutable as most number classes.)

It is like implementing a subclass of Integer that is called Zero and hardcodes some of the operations since they are trivial for zero. You could do this, as every zero is an integer, but don't make it public, hide it behind a factory method.