instanceof

[Jeremy Watts]

I have three classes, 'Number', 'Integer' & 'Rational', as below:-

public abstract class Number
{
    abstract Number add(Integer number);
    abstract Number add(Rational number);
    
    public Number add(Number number)
    {
        if (number instanceof Integer == true)
        {
            return(this.add((Integer)number));
        }
        else
        {
            return(this.add((Rational)number));
        }
    }
}


public class Integer extends Number
{
    (Constructor goes here...)

    public Integer add(Integer number)
    {
        (Does stuff)
    }

    public Number add(Rational number)
    {
        (Does stuff)
    }
}



public class Rational extends Number
{
    (Constructor goes here...)

    public Number add(Integer number)
    {
        (Does stuff)
    }

    public Number add(Rational number)
    {
        (Does stuff)
    }
}

Now, if I do something like :-
Number n1 = new Integer("2");
Number n2 = new Rational("3/4");
Number result = n1.add(n2);

then, is there any way of doing this, without using the 'instanceof' command
in the Number class? I've read that using this is bad practice, but I can't see
any other way around it.

[Edit - added code tags - see UseCodeTags for details]

[Paul Clapham]

In this particular case I would make Integer a subclass of Rational (an integer IS-A rational number), and then get rid of the concept of Number entirely. Which makes the problem go away until you decide to incorporate irrational numbers into your application.

[Matthew Brown]

I don't think it's ever a good design for superclasses to have to know about their subclasses. Which means that there shouldn't be any references to Integer or Rational in your Number class.

[James Boswell]

Also, rename Integer to something that doesn't conflict with a core Java class name.

[Jeremy Watts]

@Paul, I have good reason for the inclusion of the 'Number' class. The main one being that, I never know in advance what any particular arithmetic method is going to return. For example, two Integers added/subtracted/multipled will always produce an Integer, but not so Rationals. Two Rationals added may produce an Integer, for example. So, what do you use as a return type in your methods in these cases? Well, you'd need something abstract, hence 'Number'. The situation gets more complicated with the addition of other number types, such as Complex numbers, Gaussian Integers etc

There are other reasons too. Such as using 'Number' to include methods that implement algorithms that apply to all number types.

[Campbell Ritchie]

What about making your classes implement a RationalNumber interface? You ought not call it Number, for the same reason you ought not to use the name Integer.

[Matthew Brown]

Jeremy Watts wrote:@Paul, I have good reason for the inclusion of the 'Number' class. The main one being that, I never know in advance what any particular arithmetic method is going to return. For example, two Integers added/subtracted/multipled will always produce an Integer, but not so Rationals. Two Rationals added may produce an Integer, for example.

I really don't think it's a good idea to have 1/2 + 1/4 return a Rational, and 1/2 + 1/2 return a number of a completely different type! That's going to get very messy. I would expect a Rational added to a Rational to always return a Rational, and since integers are rational numbers that shouldn't be a problem.

[Jeremy Watts]

@Campbell, Yes thanks, an interface worked well! And thanks everyone else who replied

[Campbell Ritchie]

You’re welcome