views:

89

answers:

3

I keep coming back to variants of this problem: it probably has a very simple solution, but I can't seem to figure it out...

I have a bunch of classes of the form xQuantity, e.g. DistanceQuantity, AreaQuantity, etc., which extend a class DimensionQuantity. Now you can add or subtract DistanceQuantity's or AreaQuantity's, etc., but you can't mix them, so I think I need to have (short) add, subtract, etc., methods in the subclasses, but I want to reduce any logic duplication to a minimum. However, I need to return an object of the subclass, and this seems difficult to do from the superclass method. I believe this can be done using reflection, but AFAIK you still need to do a cast at the end in the subclass method, and I am told that reflection can be expensive... The best I have come up with so far is:

In DistanceQuantity (and the other similar ones):

public DistanceQuantity() {     
}

public DistanceQuantity add(DistanceQuantity d1) {
    DistanceQuantity dn = new DistanceQuantity(); 
    Object o = super.add(dn, this, d1, DistanceUnit.REF_UNIT);
    return (DistanceQuantity) o;
}

In DimensionQuantity (minus some less relevant statements):

public Object add(DimensionQuantity dn, DimensionQuantity d1, DimensionQuantity d2, 
  AbstractUnit au) {
    dn.unit = au;
    dn.scalar = d1.scalar + d2.scalar;
    dn.units = dn.scalar;    
    return dn;   
}

Can anyone come up with leaner code - that is still type-safe? TIA

+3  A: 

You can use Generics like this :

public abstract class DimensionQuantity<T extends DimensionQuantity>{
    public abstract T add(T parameter);
}

and you extends it like this :

public class DistanceQuantity extends DimensionQuantity<DistanceQuantity>{
    public DistanceQuantity add(DistanceQuantity parameter){
        //Whatever
        return null;
    }
}

And for the initial question, it's a really bad idea (and a bad practice) to have a superclass which uses one of its sub-classes.


Resources :

On the same topic :

Colin Hebert
it's better (clearer once you have lots of generics) to name the generics something closer to T_DimensionQuantity
Egwor
You forgot the abstract keyword. ;) Just using 'T' is pretty standard practice I think.
Michael Angstadt
@mangst thanks, it's abstract now. @Egwor, like @mangst said, T is common. T for Type, in Collection it's E for Element, in Map it's K and V for Key and Value. Usually it's the first letter of your generics meaning.
Colin Hebert
@Colin Do you consider the design of the `Ordering` class from Guava also bad, because it relies directly on sub classes (`nullsLast`, `reverse`, ...)? Just curious.
Willi
@Willi Schönborn Well, to be precise as long as the subclasses aren't part of the public interface of the parent, it's not that bad. And I shouldn't have used "Design flaw" but rather "Bad practice".
Colin Hebert
@Colin HEBERT and @Benoit Courtine both seem to like generics, but you both apparently missed (and I forgot to point it out) that I want the '+' in the superclass, *not* in the subclass. And @Colin's code returns null, which is exactly the wrong answer! So maybe super/subclassing is not the right approach...
Paul Morrison
"It returns null"... Are you kidding me ?!?
Colin Hebert
You want the add() method in the super class ? What does this means ? Give some examples.
Colin Hebert
@Colin - I am seeing //Whatever return null; }}Aren't you?
Paul Morrison
I want to put shared logic in a common place - I suspect subclass/superclass is the wrong technique. It would probably be better to use a Helper class. I'll try that...
Paul Morrison
@Paul Morrison, of course, you have to replace the content of `add()` with your own logic and return your result. And I think that you're trying to solve a conception problem by adding another conception problem. You shouldn't put every possible `add()` variant in a common place, it's really hard to maintain and it isn't scalable at all. What if you create a new subclass of `DimensionQuantity` ? What if another developer which can't access to your helper code wants to create its subclass ? You should really look at this solution first.
Colin Hebert
A: 

In Java 6, you can try something like that. But using generics is also a good idea :

public abstract class DimensionQuantity {

    protected int quantity;

    public DimensionQuantity (int quantity) {
        this.quantity = quantity;
    }

    public abstract DimensionQuantity add(DimensionQuantity dq);
}

public class DistanceQuantity extends DimensionQuantity {

    public DistanceQuantity(Quantity quantity) {
        super(quantity);
    }

    /* 
     * A sub-class as return type is authorized.
     * If dq is not a DistanceQuantity, a ClassCastException is thrown, but you can change this.
     */
    @Override 
    public DistanceQuantity add(DimensionQuantity dq) throws ClassCastException {
        return new DistanceQuantity(this.quantity + (DistanceQuantity) dq.quantity);
    }
}
Benoit Courtine
But now you can add an AreaQuantity to your DistanceQuantity.
Colin Hebert
Yes, but this will result in a ClassCastException. So this action is forbidden and will be detected quickly (but at runtime and not a compilation).
Benoit Courtine
It's really dangerous, and if you cast your DistanceQuantity into a DimensionQuantity you don't even know what to do without risking a CCE.
Colin Hebert
A: 

Create an enum for the Dimensions:

public enum Dimension { AREA, DISTANCE,...}

Throw away your subclasses. Instead create only DimensionQuantity objects, and force each to have an (immutable) Dimension, set at create time.

Implement addition in DimensionQuantity, first checking that the Dimensions of the two quantities being added are the same.

Voila! Fewer classes, type safety, no duplicate code.

DJClayworth
"first checking that the Dimensions of the two quantities being added are the same. " - that sounds like run-time to me!
Paul Morrison