Is it OK to have object instantation 'hooks' in base classes?

Question

I have created my own Tree implementation for various reasons and have come up with two classes, a 'base' class that is a generic tree node that is chock full of logic and another class that extends that one which is more specialised.

In my base class certain methods involve instantiating new tree nodes (e.g. adding children). These instantations are inside logic (in a nested loop, say) which makes the logic hard to separate from the instantation.

So, if I don't override these instantations in the specific class the wrong type of node will be created. However, I don't want to override those methods because they also contained shared logic that shouldn't be duplicated!

The problem can be boiled down to this:

public class Foo {
    public String value() { return "foo"; }

    public Foo doStuff() {
     // Logic logic logic..
     return new Foo();
    }
}

class Bar extends Foo {
    public String value() { return "bar"; } 
}

new Bar().doStuff().value(); // returns 'foo', we want 'bar'

The first thing that popped into my head would have a 'create hook' that extending classes could override:

public Foo createFooHook(/* required parameters */) {
  return new Foo();
}

Now. while it was a fine first thought, there is a stench coming off that code something awful. There is something very... wrong about it.

It's like cooking while naked-- it feels dangerous and unnecessary.

So, how would you deal with this situation?

Answer 1

I don't think there's a better approach. Just be careful not to call these hooks from the constructor.

Answer 2

So, after getting my copy of Design Patterns and opening it for what I'm fairly sure is the first time ever I discovered what I want.

It's called the Factory Method and it's mostly a perfect fit. It's still a bit ugly because my super class (Foo in the above example) is not abstract which means subclasses are not forced to implement the hook.

That can be fixed with some refactoring though, and I'll end up with something to the effect of:

abstract class AbstractFoo {
    public String value() { return "Foo"; }

    public AbstractFoo doStuff() {
        // Logic logic logic
        return hook();
    }

    protected abstract AbstractFoo hook();
}

class Foo extends AbstractFoo {
    protected AbstractFoo hook() { return new Foo(); }
}

class Bar extends AbstractFoo {
    public String value() { return "Bar"; }

    protected AbstractFoo hook() { return new Bar(); }
}

new Bar().doStuff().value(); // Returns 'Bar'!

Answer 3

In addition to the Factory pattern, I'd take a look at the Composite pattern - it tends to lend itself well to working with a Factory in tree-based situations.

Composite Design Pattern