Double Dispatching in Java

Overview

This is an example and explanation of double dispatching in Java, just to add to the collection :-)

The following is the entrypoint to the thread on this topic:

• Re: Double dispatching in Java

Original Posting: Double-dispatching in Java

Roedy Green wrote:
> >double dispatching
>
> Would anyone care to post a small code snippet, preferably in Java or
> C++, that demonstrates what double dispatching is?

OK, I will give a relatively concise one in Java. Please see the GOF Design Patterns Book, The Smalltalk Design Patterns Companion, Kent Beck's Best Practice Patterns, and so on for more information and more detailed examples.

Say I need a 2D-Point with highly accurate X and Y numeric values:

import java.math.*;

class Point2D implements Addable {
    protected final BigDecimal myX;
    protected final BigDecimal myY;

    public Point2D(BigDecimal x, BigDecimal y) {
        myX = x;
        myY = y;
    }

    public BigDecimal getX() {
        return myX;
    }

    public BigDecimal getY() {
        return myY;
    }

    public String toString() {
        return "";
    }
}

I certainly would like to be able to add points together:

    public Point2D addToPoint(Point2D aPoint) {
        return new Point2D(
                this.getX().add(aPoint.getX()),
                this.getY().add(aPoint.getY())
            );
    }

And I decide I would also like to be able to add numbers to points. I will consider the number to be just an X value of a "virtual" point (so the Y value is considered '0'):

    public Point2D addToBigDecimal(BigDecimal aBigDecimal) {
        return new Point2D(
                getX().add(aBigDecimal),
                getY()
            );
    }

class PointTest {
    static public void main(String[] args) {
        Point2D p1        = new Point2D(new NewBigDecimal("5"), new NewBigDecimal("6"));
        Point2D p2        = new Point2D(new NewBigDecimal("3.1"), new NewBigDecimal("4.5"));
        NewBigDecimal bd1 = new NewBigDecimal("7.2");
        NewBigDecimal bd2 = new NewBigDecimal("9.1");

        System.out.println("P1  = "  + p1);
        System.out.println("P2  = "  + p2);
        System.out.println("BD1 = " + bd1);
        System.out.println("BD2 = " + bd2);

        System.out.println();
        System.out.println("*Results*");
        Object result1a = p1.addToPoint(p2);
        Object result2a = p1.addToBigDecimal(bd1);

        System.out.println("P1+P2  = "+result1a);
        System.out.println("P1+BD1 = "+result2a);
    }
}

       Object result3a = p1.addTo(p2).addTo(bd1);

    public Point2D addTo(NewBigDecimal value) {
        return addToBigDecimal(value);
    }
    public Point2D addTo(Point2D value) {
        return addToPoint(value);
    }

I have now collapsed my longer names into shorter (overloaded) names and so can ignore whether a given argument is a point or a number.

Cool, I now have short operation names, and the program will choose between them based upon... No, wait... the only reason the above 'result3a' works is because I told the compiler what types the variables 'p2' and 'bd1' are. If I am getting these objects out of a collection, I will not know what type of object they are specifically, I will only know they an be added to a Point. The compiler can not tell me the difference, only the runtime object can. If both a1 and a2 are extracted from an Enumeration, the following:

        Object a1, a2;
        Object result3b = p1.addTo(a1).addTo(a2);

OK, wrong path (stupid overloading), so I switch to a more generic 'addTo' and a type check:

    public Point2D addTo(Object value) {
        if (anObject instanceof NewBigDecimal) return addToBigDecimal(value);
        if (anObject instanceof Point2D) return addToPoint(value);
        //....
    }

    public Point2D addTo(Object value) {
        return value.addToPoint(this);
    }

        Object result3b = p1.addTo(a1).addTo(a2);

    return value.addToPoint(this);

Except we are in Java and I slipped in a bit of "optimistic" untyped code and left out a little of the implementation. Objects in Java would not know how to handle 'addToPoint' and Java would not know that 'addToPoint' returns a Point2D. Unfortunately, things get even messier VERY quickly with Java because it does not have Covariant return types, we can not augment existing classes, and so on. The following is a fuller set of code to make the above really work:

/**
An addable is an object that can be added to another object.  The exact
meaning of that addition
depends on the two objects involved.
**/
interface Addable {
    Addable addTo(Addable anObject);

        /**
         *This is really "private" within the Addable implementations
         */
    Addable     addToBigDecimal(NewBigDecimal aBigDecimal);

        /**
         *This is really "private" within the Addable implementations
         */
    Addable         addToPoint(Point2D aPoint);
}


/**
NewBigDecimal is simply the BigDecimal class with the additional
operations
of the Addable interface.

We just want to augment BigDecimal with 'addTo' methods, but Java does
not support augmentation of existing classes so we have to create our
own subclass.
**/
class NewBigDecimal extends java.math.BigDecimal implements Addable {
    public NewBigDecimal(String val) throws NumberFormatException {
        super(val);
    }
    public Addable addTo(Addable addable) {
        return addable.addToBigDecimal(this);
    }
    public Addable  addToBigDecimal(NewBigDecimal aBigDecimal) {
            //Hack to handle the class conversion between BigDecimal and NewBigDecimal
        return new NewBigDecimal(this.add(aBigDecimal).toString());
    }
    public Addable addToPoint(Point2D aPoint) {
            //just reverse the call because Points are more interesting then BigDecimals
        return aPoint.addToBigDecimal(this);
    }
}

import java.math.*;

class Point2D implements Addable {
    final BigDecimal myX;
    final BigDecimal myY;
    public Point2D(BigDecimal x, BigDecimal y) {
        myX = x;
        myY = y;
    }
    public Addable addTo(Addable addable) {
        return addable.addToPoint(this);
    }
    public Addable  addToBigDecimal(NewBigDecimal aBigDecimal) {
        return new Point2D(
                getX().add(aBigDecimal),
                getY()
            );
    }
    public Addable addToPoint(Point2D aPoint) {
        return new Point2D(
                this.getX().add(aPoint.getX()),
                this.getY().add(aPoint.getY())
            );
    }
    public BigDecimal getX() {
        return myX;
    }
    public BigDecimal getY() {
        return myY;
    }
    public String toString() {
        return "";
    }
}


class PointTest {
    static public void main(String[] args) {

        Point2D p1        = new Point2D(new NewBigDecimal("5"), new NewBigDecimal("6"));
        Point2D p2        = new Point2D(new NewBigDecimal("3.1"), new NewBigDecimal("4.5"));
        NewBigDecimal bd1 = new NewBigDecimal("7.2");
        NewBigDecimal bd2 = new NewBigDecimal("9.1");

        Addable a1 = p2;
        Addable a2 = bd1;
        Addable a3 = bd2;

        System.out.println("P1  = "  + p1);
        System.out.println("P2  = "  + p2);
        System.out.println("BD1 = " + bd1);
        System.out.println("BD2 = " + bd2);

        System.out.println();
        System.out.println("A1 = " + a1);
        System.out.println("A2 = " + a2);
        System.out.println("A3 = " + a3);

        System.out.println();
        System.out.println("*Results*");
        Object result1a = p1.addTo(p2);
        Object result2a = p1.addTo(bd1);
        Object result3a = p1.addTo(p2).addTo(bd1);

        Object result1b = p1.addTo(a1);
        Object result2b = p1.addTo(a2);
        Object result3b = p1.addTo(a1).addTo(a2);


        Object result4 = a2.addTo(a1);
        Object result5 = a3.addTo(a2);

        System.out.println("P1+P2  = "+result1a);
        System.out.println("P1+BD1 = "+result2a);
        System.out.println("P1+P2+BD1 = "+result3a);

        System.out.println("P1+A1 = "+result1b);
        System.out.println("P1+A2 = "+result2b);
        System.out.println("P1+A1+A2 = "+result3b);

        System.out.println("A2+A1 = "+result4);
        System.out.println("A3+A2 = "+result5);


    }
}

Some C++ examples and relatively recent discussions are at:

• http://www.dejanews.com/getdoc.xp?AN=434895723
• http://www.dejanews.com/getdoc.xp?AN=433471006

--Mark
mark.fussell@chimu.com

Subsequent Discussions

Adding more classes

Steve Wart wrote:
> Mark Fussell wrote in message <36B648A9.F98571CC@chimu.com>...
> >Roedy Green wrote:
> >> Would anyone care to post a small code snippet, preferably in Java or
> >> C++, that demonstrates what double dispatching is?
> >
> >OK, I will give a relatively concise one in Java.  Please see the GOF
> >Design Patterns Book, The Smalltalk Design Patterns Companion, Kent
> >Beck's Best Practice Patterns, and so on for more information and more
> >detailed examples.
> >
> [ amazingly comprehensive example deleted ]

> What happens as more classes need to implement the Addable interface?
> Do things get more complex in a combinatorial way?

It isn't combinatorial because you only have a single entry per type of object that you will need for the second dispatch. The number of dispatching operations could be equal to the number of implementation classes (times the number of "actual" operations), but it is likely to be somewhat smaller than that if there is no externally important difference for the particular type's perspective. For example, you could have Colored-2d-Points without extending the the Addable interface.

It does cause a focal point (bottleneck) in that Addable interface: you have to have the union of all dispatching operations within it, so it will be hard to "close" it against future changes. The other option is to keep creating subtypes of the interface ("MoreAddable extends Addable") that have new capabilities, but this then returns us to the starting problem of needing to behave differently depending on what the type of the argument is. Say MoreAddable understands ColoredPoints where Addable only understands Points. Then the staticly bound version would be:

    public ColoredPoint2D addTo(Addable value) {
        return value.addToPoint(this);
    }

    public ColoredPoint2D addTo(MoreAddable value) {
        return value.addToColoredPoint(value);
    }

    public Point2D addTo(Addable value) {
        if (anObject instanceof MoreAddable) {
             return value.addToColoredPoint(value);
        } else {
             return value.addToPoint(this);
        }
    }

> Is this what people are talking about when
> they speak of the strengths of strong typing or is this a contrived example to make a Java
> implementation look much more complex than the Smalltalk equivalent?

Strong typing certainly becomes more "cumbersome" as flexibility needs to increase and the runtime objects determine more and more of the desired behavior. Generally, this just discourages producing these types of very generic structures (e.g. no general "Magnitude" / Addable in Java).

> Or is it really not that bad, I am just so used to Smalltalk that it seems worse than it is?

--Mark
mark.fussell@chimu.com

Difficulty of double-dispatch in Java compared to Dylan

Peter wrote:
> Mark Fussell wrote:
> > OK, I will give a relatively concise one in Java.
>
> [huge 9,300 character example deleted]
>
> I'd hate to see a verbose example.  :-)

{Within Addable}
    Addable     addToBigDecimal(NewBigDecimal aBigDecimal);
    Addable     addToPoint(Point2D aPoint);

{Within NewBigDecimal}
    public Addable addTo(Addable addable) {
        return addable.addToBigDecimal(this);
    }

{Within Point2D}
   public Addable addTo(Addable addable) {
        return addable.addToPoint(this);
    }

> It seems like an exercise in frustration to simulate a limited form of
> multi-method disptach in these mono-dispatch language.  Why settle for a
> substitute when you can have the real thing.

This is a more interesting topic: what are the advantages and disadvantages of changing to a multi-dispatch form over a single-dispatch form. Since I have a version of multi-dispatching in Smalltalk, I might as well try to comment on that, but it is a longer and separate post.

[[Rest of discussion snipped... tangential topic]]

--Mark
mark.fussell@chimu.com