Abstract classes, and 'instanceOf'

Ok, I have 3 classes, An abstract one (called 'NumberType'), and two standard ones (called 'Real' & 'Complex'). The two standard classes are child classes of the abstract class.

As you may have guessed, these things do basic arithmetic on real & complex numbers. Inside each, are overloaded methods handling all combinations of the basic operations - such as a 'real added to a real', a 'real added to a complex', a 'complex added to a real', a 'complex added to a complex' and so on..

And then, inside the NumberType class, I have abstract methods such as:-

abstract NumberType add(Real number);
abstract NumberType add(Complex number);

The reason that the return type here is 'NumberType', (and also the entire point of this class's existence anyway), is that upfront, there would be no way of knowing what type of number would be returned by this method. For instance, two complex numbers added, may in some instances, return a real number. And similar for other combinations.

Now, I also have included a non-abstract method in the NumberType class, that handles
a NumberType added to a NumberType. It goes like this:-

Code java:

---

    public NumberType add(NumberType number)
    {
        if (number instanceof Real == true)
        {
            return(this.add((Real)number));
        }
        else
        {
            if (number instanceof Complex == true)
            {
                return(this.add((Complex)number));
            }
        }
    }

---

Now, finally, the point of my entire question. Is there anyway of doing this without having to resort to using the rather frowned-upon 'instanceOf' statement? I have tried a few things, without success, such as generics. But cannot get anything to work, without using instanceOf.

Thanks

Why doing this?The method add is overloaded,so when called with real or complex number,at compilation time the compiler will select the right one.You do not need to check it by yourself.

Sure, yes.. but what I neglected to mention in my original post, was something like this:-

Lets say, that I am initially adding two numbers of the Complex class, then because I will not know what type of number will be returned here straight off (for example, two complex numbers added may return another complex, or possibly a real), then my 'return type' for the addition call, has to be of NumerType type. For example:-

Complex c1 = new Complex(2, 3);
Complex c2 = new Complex(4, -3);

NumberType result = c1.add(c2);

(in this example, then a real is actually returned)

Now, what if i want to use this 'result' in a further calculation? Such as:-

Real t = new Real(5.0);

NumberType newResult = t.add(result);

Here then, I must include code to handle the case of a 'Real' being added to a 'NumberType', which is the code in the NumberType class, containing the 'instanceOf' statements.. which are the very thing I wish to avoid using.

So i you not implement an add with NumberType as argument then you probably get a compiler error.You could cast inside this add function to real and then check for a null exception.If this exception is not thrown then it is ok,so you call the right add method.Then you could do the same for complex.But this is more inefficient than the instance of style you posted before(in my opinion)

Why not have every number be complex? By definition a real number is just a complex number with a zero imaginary part.

Sure, yes, that is possible, and is something that I originally thought of doing. But there are soliid reasons why I want to do it this way. One is that of computational efficiency, treating reals as separate to complex's allows a more efficient multiplication algorithms, for instance. This may sound slightly trivial, but if you're carrying out very many of these computations, then the efficiency improvement is noticeable.

The second reason is that the subject of maths (or math, if you're American) itself makes clear distinction between number types (it has different set notations for each, R (for reals), C (for complex numbers), Z (for integers) etc etc. and i wish to make use of these distinctions further down the line.

I think this is an case of trying to prematurely optimize your code.

Handling all potentially complex numbers as purely complex isn't that slow. It's definitely not slow compared to the checks required to determine if the result should be real or complex or which method to call. There just isn't a way to know this at compile time so any solution will require runtime computation. This is further complicated by memory and SIMD optimizations (which I'm not sure to what extend Java can take advantage of).

It also adds unnecessary code bulk which makes code maintenance more difficult.

If you know a computation will always be real, I would suggest you stick with the primitive doubles and floats. Otherwise, you will have to incur the penalty of using complex numbers.