Java Design Patterns – Inheritance vs Dynamic Proxy for Class Functionality

designdesign-patternsjavaobject-oriented

Currently I have three classes and respective interfaces and respective builders:

Tree: the data structure (implemented in SimpleTree)
ProbabilityTree: is a Tree with added functionality to randomly select child nodes and to adjust the probability of selecting a node (implemented in ProbabilityTreeImpl).
DynamicTree: is a ProbabilityTree which dynamically constructs nodes when a requested node doesn't exist yet.

The client code needs Trees that support both random selection of nodes, as provided by ProbabilityTree, and the tree dynamically growing when yet unexisting nodes are requested, as provided by DynamicTree.

NOTE: Currently all three trees are immutable after having been build; for DynamicTree this means clients cannot add or remove nodes, but the tree itself can automatically change.

NOTE: See Github gist with the five Java classes for the code.

There are at least two issues with this design:

DynamicTree is derived from ProbabilityTree, while conceptionally these two capabilities are unrelated (i.e. orthogonal).
Using inheritance to add functionally is often considered "bad design" (correct me if I'm wrong here).

An alternative design would be to decouple ProbabilityTree and DynamicTree using something similar to the decorator and/or adapter pattern. Using Java's dynamic Proxy might enable "decorators" that extend the interface and that can decorate other Trees with extended interfaces; i.e.:

TreeDecorator implements InvocationHandler, ... {
    Tree adapted;
    ...
    Object invoke(Method method, Object[] args) {
        if( «this class can/should handle method» ) {
            return method.invoke(this, args);
        } else if ( «this.adapted can/should handle method» ){
            return method.invoke(adapted, args);
        }
    };
}

Again there are some issue's:

Using Proxy makes the code more difficult to understand.

What shall I do? Use inheritance to extend functionallity, use dynamic proxy, or something else?

Best Answer

I can think of 3 reasonable options, depending on what you really need (right now), and how complex your code is.

(What you currently call DynamicTree, I call DynamicProbabilityTree)

If the only thing you really need is a DynamicProbabilityTree, and you feel like your code is simple enough to fit in one class, put all your code inside DynamicProbablityTree, and get rid of your other classes.
If the only thing you really need is a DynamicProbabilityTree, but you feel like you code is too complex to fit into one class, keep your code for the tree structure in SimpleTree, and put the dynamic and probability code in DynamicProbabilityTree. I would recommend that DynamicProbabilityTree contain and delegate to a Tree instead of inheriting; inheriting would also work.
If you really need a SimpleTree, ProbabilityTree (that is not dynamic), DynamicTree (that does not do probability), and DynamicProbabilityTree, use the Decorator pattern.

Related Solutions

Java Design Patterns – Is This a Good Case for Proxy Pattern or Overdone?

The big thing here is what are the chances you'll need to do this for other clients? If the odds of any other client using this are low to nil, refactoring may be a lot of time and effort for something with very minor impact. However, if you think this could be an enhancement you'll be making for more clients, I would go ahead and make the change to the code.

If you do refactor, I think the Strategy pattern is a better fit for this particular situation. It sounds like you're not so much looking for an object to operate in place of another object so much as you're looking to alter the server's behavior based on the specific situation. Clients (I'm assuming at this point that ultimately this will be used by more than 1 client) that would use this enhancement would use a strategy that checks existing orders before sending out a new order, other clients would use a strategy that always sends orders to market. As clients start to use this feature, they use the appropriate strategy with minimal changes on your part.

C# Visitor Pattern – Using with Large Object Hierarchy

I have been using the visitor pattern to represent expression trees over the course of 10+ years on six large-scale projects in three programming languages, and I am very pleased with the outcome. I found a couple of things that made applying the pattern a lot easier:

Do not use overloads in the interface of the visitor

Put the type into the method name, i.e use

IExpressionVisitor {
    void VisitPrimitive(IPrimitiveExpression expr);
    void VisitComposite(ICompositeExpression expr);
}

rather than

IExpressionVisitor {
    void Visit(IPrimitiveExpression expr);
    void Visit(ICompositeExpression expr);
}

Add an "catch unknown" method to your visitor interface.

It would make it possible for users who cannot modify your code:

IExpressionVisitor {
    void VisitPrimitive(IPrimitiveExpression expr);
    void VisitComposite(ICompositeExpression expr);
    void VisitExpression(IExpression expr);
};

This would let them build their own implementations of IExpression and IVisitor that "understands" their expressions by using run-time type information in the implementation of their catch-all VisitExpression method.

Provide a default do-nothing implementation of `IVisitor` interface

This would let users who need to deal with a subset of expression types build their visitors faster, and make their code immune to you adding more methods to IVisitor. For example, writing a visitor that harvests all variable names from your expressions becomes an easy task, and the code will not break even if you add a bunch of new expression types to your IVisitor later on.