Using multiple frameworks in C++ and Java by Alan Griffiths

Abstract

In an application that is using more than one framework there are occasions when it is desirable for a single object to perform a role in two (or more) frameworks. We investigate two design alternatives for combining default implementations provided by the frameworks with a user defined class that interacts with both.

Outline implementation for these designs are given C++ and Java. As a result we reach the surprising conclusion that in changing from one implementation language to the other it is correct to change between these design alternatives.

Sidebar: Application Frameworks, Mixins and Adapters

Introduction

The idea for this article came from a discussion with a colleague working in Java about the difficulties he was having trying to combine his extensions to a user interface framework (in this case Sun's Swing) with the need to integrate these extensions with a framework that provides an undo facility.

Although I've been dabbling with Java for over two years I still tend to "think in C++" and translate my C++ approach into Java. At the design level this is usually an effective way to apply the experience I've gained over the last decade - it would be surprising if a design stopped working just because it is expressed in a different language. (Of course there are some pitfalls to avoid since C++ supports paradigms that Java doesn't - most notably generic programming.)

My initial suggestion was based on the way I've tackled similar problems in C++, by using the "mixin" idiom to interface to both frameworks and is shown below. Subsequently, I became dissatisfied with using this approach in Java. Upon examining Java code I'd written, I realised that in analogous situations I was using a different approach based on the "adapter pattern". This seems more natural in Java and is also illustrated below.

To make the following discussion concrete, let us assume that we are using two frameworks; one framework delivers the user interface, whilst the second is an engine for a board game such as chess. In writing a program we reach the conclusion that we both want to add a piece to a display in the user interface and to place it in the board. To achieve this we require a class that that implements both user interface behaviour (displaying itself) and application domain behaviour (moving on the board).

Before presenting the code I'd like to make two points:

1. In the general case framework interfaces will have a number of methods, but for the sake of brevity I show only one, and
2. in presenting these approaches in both languages I have adopted a coding style that emphasises the similarities of design but is not idiomatic in either language (e.g. it unusual to implement C++ methods in the class body).

The framework classes

Before looking at the different approaches to implementing our class we need to provide definitions in C++ and Java of the framework classes with which we will be working:

DisplayInterface

This defines the protocol used by the display framework to present an object on the screen.

Display

The part of the user interface that we wish to use to display our piece.

DefaultDisplayInterface

Provides a default, do nothing, implementation of the interface.

PieceInterface

This defines the protocol used by the game framework to manage pieces.

Board

The part of the game framework to which we wish to supply our piece.

DefaultPieceInterface

Provides a default, do nothing, implementation of the interface.

The first listings 1 and 2 provide corresponding C++ and Java code, so far the differences between the languages are minor and relate only to their syntax.

class DisplayInterface {
public:
    virtual const DisplayInterface& drawOn(DrawingSurface& surface) const = 0;
};

class Display {
public:
    void add(DisplayInterface*);
};

class DefaultDisplayInterface : public DisplayInterface {
public:
    virtual const DisplayInterface& drawOn(DrawingSurface&) const { return *this;}
};

class PieceInterface {
public:
    virtual PieceInterface& moveTo(int file, int rank) = 0;
};

class Board {
public:
    void add(PieceInterface*);
};

class DefaultPieceInterface : public PieceInterface {
public:
    virtual PieceInterface& moveTo(int, int) {return *this;}
};

public interface DisplayInterface {
    public DisplayInterface drawOn(java.awt.Graphics surface);
}

public interface Display {
    public void add(DisplayInterface d);
}

public class DefaultDisplayInterface implements DisplayInterface {
    public DisplayInterface drawOn(java.awt.Graphics surface) { return this;}
}

public interface PieceInterface {
    public PieceInterface moveTo(int file, int rank);
}

public class Board {
    public void add(PieceInterface p);
}

public class DefaultPieceInterface implements PieceInterface {
    public PieceInterface moveTo(int file, int rank) { return this; }
}

First approach: using the default implementations as mixins

In C++ default implementations from several frameworks can be used directly: As can be seen from listing 3, if the default behaviour is all that is required then there is almost nothing to it! (However, this example will be revisited below under "dealing with clashes".)

class DisplayPiece : 
    public DefaultPieceInterface,
    public DefaultDisplayInterface {
};

In Java whilst we are able to provide the default implementations, the rules governing inheritance require that we inherit from at most one of them. (Java distinguishes "interfaces" which have no implementation whatsoever from other classes - one may inherit as many interfaces as one likes and implement the required methods, but at most one "ordinary" class.)

As usual an extra layer of indirection solves the problem - listing 4 introduces an extra class whose sole purpose is to delegate the default behaviour for both interfaces whilst allowing derived classes to override those that are of interest.

// Default implementation for both frameworks
public class AbstractDisplayPieceInterface 
    implements DisplayInterface, PieceInterface {

    public DisplayInterface drawOn(java.awt.Graphics surface) {
        d.drawOn(surface);
        return this;
    }

    public PieceInterface moveTo(int file, int rank) {
        p.moveTo(file, rank);
        return this;
    }

    final private DisplayInterface d = new DefaultDisplayInterface();
    final private PieceInterface   p = new DefaultPieceInterface();
}

public class DisplayPiece extends AbstractDisplayPieceInterface {
};

Although this code proves that default interfaces can be mixed in Java I'm far from convinced that this is a good approach! There is a serious potential "gotcha" - when there are several methods defined in the interface it is possible for one of the default method implementations to be defined in terms of another - the approach shown doesn't work when only the latter method is overridden.

Second approach: deriving adapters from the default implementations

What I came to realised was that Java's "anonymous local classes" provide a very elegant alternative based on the adapter pattern described by the "Gang of Four"[1] (and that I was already using it on a regular basis).

The use of adapters frees the DisplayPiece class from the need to implement the interfaces required by the framework directly. Also an adapter for one framework doesn't need to implement any of the functionality required by the other, so multiple inheritance isn't an issue.

Listing 5 shows an implementation using this approach - the DisplayPiece class implements functionality corresponding to the methods we wish to adapt and two fragments of "client code" that create suitable adapters for the two frameworks.

public class DisplayPiece {
    private void myDrawOn(java.awt.Graphics surface) {}
    private void myMoveTo(int file, int rank)        {}
}

// "client code" fragment #1
    void addToDisplay(Display d, final DisplayPiece p) {
        d.add(new DefaultDisplayInterface(){
            public DisplayInterface drawOn(java.awt.Graphics surface) 
                {p.myDrawOn(surface); return this;}
        });
    }

// "client code" fragment #2
    void addToBoard(Board g, final DisplayPiece p) {
        g.add(new DefaultPieceInterface() {
            public PieceInterface moveTo(int file, int rank)
                {p.myMoveTo(file, rank); return this;}
        };
    }

The reason for presenting the Java code first in this approach is that in C++ we still have a major design decision to make - something needs to own the adapter classes and to control their lifetimes - they have to be deleted when they are no longer used. (In Java the "virtual machine" reclaims memory that is no longer in use, C++ requires the programmer to know when this happens and to release it herself.)

For the sake of simplicity in listing 6 I've chosen to embed the adapters as nested classes within the DisplayPiece class. This ensures that they will be deleted with it. Another valid solution is to embed them into a separate controlling class.

class DisplayPiece {
public:
    DisplayPiece() :
    pia(*this), uia(*this) {
    }

    operator PieceInterface&() {
        return pia;
    }

    operator DisplayInterface&() {
        return uia;
    }

    void myMoveTo(int, int) {
    }

    void myDrawOn(DrawingSurface&) const {
    }

private:
    class PieceInterfaceAdapter : public DefaultPieceInterface {
    public:
        PieceInterfaceAdapter(DisplayPiece& adaptee) :
        body(adaptee) {
        }

        PieceInterface& moveTo(int file, int rank) {
            body.myMoveTo(file, rank);
            return *this;
        }

        DisplayPiece& body;
    private:
        PieceInterfaceAdapter(const PieceInterfaceAdapter&);
        PieceInterfaceAdapter& operator=(const PieceInterfaceAdapter&);
    } pia;

    class DisplayInterfaceAdapter : public DefaultDisplayInterface {
    public:
        DisplayInterfaceAdapter(DisplayPiece& adaptee) :
        body(adaptee) {
        }

        const DisplayInterface& drawOn(DrawingSurface& s) const {
            body.myDrawOn(s);
            return *this;
        }

        DisplayPiece& body;
    private:
        DisplayInterfaceAdapter(const DisplayInterfaceAdapter&);
        DisplayInterfaceAdapter& operator=(const DisplayInterfaceAdapter&);
    } uia;

    DisplayPiece(const DisplayPiece&);
    DisplayPiece& operator=(const DisplayPiece&);
};

In the first approach we found the Java code to be more elaborate than the C++, now that situation has been reversed. By making the C++ framework more complex and providing a template adapter class we could perhaps reduce the complexity of the client code a little, but the requirement for explicit memory management remains.

Dealing with clashes

Returning to the first approach, there is a possibility that both interfaces may have a method with the same signature. For the sake of argument suppose that both interfaces declare a method void clash(). If we were to override this method in our DisplayPiece class then we would have difficulty determining through which interface we were being invoked.

In C++ this issue can be resolved by adding a pair of intermediate classes into the hierarchy that effectively rename the message so that we can determine its origin. Listing 7 shows the way.

class IntermediateDisplay : public DefaultDisplayInterface {
public:
    // DO NOT OVERRIDE clash() - override displayClash() instead
    virtual void clash() { displayClash(); }
    virtual void displayClash() { DefaultDisplayInterface::clash(); }
};


class IntermediatePiece : public DefaultPieceInterface {
public:
    // DO NOT OVERRIDE clash() - override pieceClash() instead
    virtual void clash() { pieceClash(); }

    virtual void pieceClash() { DefaultPieceInterface::clash(); }
};


class DisplayPiece : 
    public IntermediatePiece, 
    public IntermediateDisplay {
};

As this technique relies on multiple inheritance there is no corresponding solution in the Java case.

Final thoughts

In a very real sense we have been looking at two different formulations of a single idea - an object that can interact with both the display and the board. What is surprising is that the choice of implementation language has such a dramatic effect on the ease with which each approach can be expressed. It could be argued that the correct translation of listing 3 is not listing 4 (which is not idiomatic Java), but listing 5 (which is).

The idea that an "adapter" is the correct translation of a "mixin" seems strange at first but Kevlin Henney[2] has previously observed similar relationship between "iteration" and "enumeration" when moving between languages. This change of form as a result of translation isn't just a characteristic of computer languages - Douglas Hofstadter[3] dedicates a substantial volume to similar interactions between the ideas being expressed and the forms of expression in different natural languages.

Why does changing the implementation language change the way in which the problem is solved?

1. The mixin approach works well in C++ because it removes the problem of object lifetimes that occurs in the adapter approach. In addition, the more flexible C++ inheritance model allows default behaviours to be combined and the occasional problem of methods clashing to be resolved.
2. The adapter approach works well in Java both because of the lightweight syntax for declaring anonymous local classes and because the JVM, not the programmer has responsibility for controlling object lifetimes.

Mixins and adapters are both idioms I've used before, but I hadn't previously considered the possibility of a relationship between them. I see now that they are very close and solve related problems. The choice between them may depend on the fine detail of the problem at hand.

For those that wish to draw conclusions about the superiority of one language or the other I've shown that both choices are always available in C++, whilst the mixin approach may sometimes be problematic in Java. On the other hand the adapter approach is sufficient in Java and very flexible.

References