Java Tiger - Visitor return type

I've been playing with generics in the latest JDK (among other features) to see how many of the features are useful in my eternal JavaSauce project. Quite a few as it happens. Annotations, varargs, new for loop iteration, static imports. And generics. In particular generics for the Visitor Pattern. Here's what I had before Tiger (some class names changed to save typing):

public interface Visitable
{
    void accept(Visitor visitor);
}

public interface Visitor
{
    void visit(A visited);
    void visit(B visited);
    void visit(C visited);
}

These interfaces allow me to visit the A, B, and C classes which all live in the same package and particpate in a Composite relationship (as is often the case). Given the recursive whole-part relationships there's a strong temptation to make the return type boolean instead of void. However, some concrete Visitors don't need or use a return type so for these classes the void return type is preferable. There's a definite tension. Generics can help. Here's what I've now got:

public interface Visitable
{
    <R> R accept(Visitor<R> visitor);
}

public interface Visitor<R>
{
    R visit(A a);
    R visit(B b);
    R visit(C c);
}

One slight problem with this approach is that R can only be a reference type:

public final class SomeVisitor
    implements
        Visitor<boolean>  // compile time error
{    ...
}

A small Adapter can help to solve this:

public final class BooleanVisitorAdapter
    implements
        Visitor<Boolean>
{
    public BooleanVisitorAdapter(final BooleanVisitor adaptee)
    {
        this.adaptee = adaptee;
    }

    public Boolean visit(final A visited)
    {
        return Boolean.valueOf(adaptee.visit(visited));
    }

    public Boolean visit(final B visited)
    {
        return Boolean.valueOf(adaptee.visit(visited));
    }

    public Boolean visit(final C visited)
    {
        return Boolean.valueOf(adaptee.visit(visited));
    }

    private final BooleanVisitor adaptee;
}

public interface BooleanVisitor

{
    boolean visit(A visited);
    boolean visit(B visited);
    boolean visit(C visited);
}

Allowing:

someObject.accept(new BooleanVisitorAdapter(
    new BooleanVisitor()
    {
        public boolean visit(final A visited) { ... }
        public boolean visit(final B visited) { ... }
        public boolean visit(final C visited) { ... }
    }));

Note how the adapter creates a Boolean from a boolean. That could be handy; it could avoid the client writing

new Boolean(true)

which would cause needless pressure on the garbage collector (remember this is in a recursive context).

Talk in Newcastle Dec 9th

I've been invited to speak at a BCS SPA-NE meeting in Newcastle on December 9th. show details

Caller has Custody

I recently discussed the idea of custody with Kevlin Henney. The general rule in software is the caller has custody. This is perhaps one of those things that's obvious once you realize but that until you realize it you might miss it. To take a simple example - calling a method with an argument. If the argument is a value there is no custody to worry about. But what if the argument is a pointer (or reference - something that creates a level of indirection).

void method(type * p);

Caller Has Custody is concerned with deciding who has custody for the object p points to. Who is responsible for creating/destroying that object? And the answer, clearly, is the code calling the method. It's not the method itself. Less experienced programmers (to generalize horribly) seem to be overly worried by this and, particularly in C++, have a tendency to use smart pointers to express this rather than using a simple raw pointer.

Perhaps Caller Has Custody is not quite so obvious for constructors. It's natural for a constructor to remember the information passed in via its parameters.

class eg
{
public:

    eg(type * p)
        : p(p)
    {
    }
    ...
}

Perhaps the nagging doubt with a constructor is that since a constructor creates a new object any information saved as part of the state of the object can easily persist beyond the duration of the constructor call itself. Perhaps that's why (again to generalize horribly) less experienced programmers seem to want to copy/clone the argument - that way the callee can take custody of the clone, and the newly created object becomes completely self contained; free from any lifetime dependencies on anything outside itself.

class eg
{
public:

    eg(type * p)
        : p(p ? p->clone() : 0)
    {
    }
    ...
}

This has a supercial attraction but it's not a good road to take. The right road is to take a deep breath and, just like in real life, accept the interdependent nature of things. A big part of mastering object-oriented programming is mastering the nature of the connections. We all chant the mantra low-coupling high-cohesion but rarely do we really embrace it. By definition a highly cohesive class does one thing and one thing only. It has a single defining responsibility. That implies two things: first, cohesive classes tend to be small and second, systems are composed of lots of objects. But all the objects in a system have to be connected together (if they're not then you've got more than one system). Thus an important part of designing an object is designing it's connections to other objects. Objects are never totally self contained. They always live in a larger context, and it's the larger context that gives them meaning.