使用类型安全性对抽象合成进行建模

Question

I have a structural problem that I could use your help with. I'll explain the abstract problem first, then an example to illustrate the problem.

Consider an abstract class holding a number of instances of an abstract class , also assume the following methods in : and . The problem arises when we inherit the classes ( inherits and inherits ) and demand that the relation has to should be the same as has to . That is, in : and . The second method will work, but not the first one (unless we do a unsafe type-cast). In other words, in : should be illegal unless parameter is an instance of . I've tried to model this relationship with generics/templates with little sucess.

This problem arises when making a graph framework. Here we have classes and . (In my actual implementation I overload GraphVertex's delete operator.) In C++:

template<class T> class Graph; // Forward reference.

template<class T> class GraphVertex
{
    public:
        GraphVertex(Graph<T> &graph) : m_graph(graph){}
        virtual ~GraphVertex() {}

        ... // Abstract methods, using T parameter.

        void remove()
        { m_graph.removeVertex(this); }
    protected:
        Graph<T> &m_graph;
}

template<class T> class Graph
{
    public:
        virtual ~Graph(){}

        ...

        virtual GraphVertex<T> *add(T val) = 0;
        virtual void removeVertex(GraphVertex<T> *vertex) = 0; // <--- !!!
}

The problem here is the method. Lets say we have implemented the classes with and . When removing a vertex in the we need more data than is provided in the abstract base class . We know that the parameter type should be but sending another type as parameter would not generate an (compile-time) error.

To solve this problem I've tried to add a new template parameter, specifying the implemented type. That is:

template<class T, class G> class GraphVertex
{
    public:
        GraphVertex(G &graph) : m_graph(graph) {}
        ~GraphVertex() {}

        ...

        void remove() { m_graph.removeVertex(this); }

    protected:
        G &m_graph;
}

template<class T, class V> class Graph
{
    public:
        virtual ~Graph() {}

        ...

        virtual V *add(T val) = 0;
        virtual void removeVertex(V *vertex) = 0;
}

template<class T> AdjacencyMatrixGraph; // Forward declaration.

template<class T> AMGVertex : public GraphVertex<T, AdjacencyMatrixGraph<T>>
{ ... }

template<class T> AdjacencyMatrixGraph : public Graph<T, AMGVertex<T>>
{ ... }

However, this will not work. It is not possible to use the base class due to circular reference of the base classes.

Graph<int> *p = new AdjacencyMatrixGraph<int>(); // Won't work.

The example above has the same problems in Java with generics.

So, is there anyway to model the relation in a type-safe way? Or am I stuck with casting pointers around?

Thank you for reading!

EDIT:

An example usage of the above could look like:

Graph<int> *someGraph = getSomeGraph();
GraphVertex<int> *newVertex = someGraph->add(3);
...
newVertex->remove();

Answer 1

Nice example (+1). The problem is in your OO design, so a type-safe solution is not possible:

Since A' is also of type A , it must follow the contract described in A . Hence foo1 of A' must accept arbitrary B as parameter, not only B' .

The return type of foo2 in A' must be of type B . Since B' is of type B , the covariant return type B' is allowed for foo2 (since n J2SE 5.0.).

Update:

To solve this dilemma, I would do a redesign, since your A' is not really an A . So either

• A' does not inherit from A , or
• A does not contain foo1 at all, or
• A must contain void a.foo1(B' val) instead.

If redesigning is too much a trouble for you, you will have to give up type safety, and, for instance, throw an Illegal Argument Exception if foo1 in A' is called with a B that is not a B' . This is quite similar to how java.util.Collection handles optional operations.

Answer 2

"When removing a vertex in the AdjacencyMatrixGraph we need more data than is provided in the abstract base class GraphVertex". I think you should write an Interface which offers the data that are needed.

If you have two sub-classes with same behavior at one point and the base-class cannot add this bahavior in it's class, because it wont't fit to every subclass you can characterize sub-classes with same bahavior with an extra interface.

Answer 3

After some experimenting I have concluded that the general design cannot be changed to be 100% type-safe. However, there are some situations where you can help ensure that the offended method is only called with the correct sub-type.

Taking the graph example, what we need to do is to insure that a sub-class of (in this case ) only can access the related sub-class of (that is for , class ). Hence insuring that the correct type is inserted at the method. To do this, a non-public visibility can be used for methods that are accessed by the abstract class . Also the visibility of the constructors of all the sub-types of must be non-public. Of course the constructor of must be visible from and the must be visible from . In C++ this can be done with friends .

template<class T> class GraphVertex
{
    public:
        virtual ~GraphVertex() {}
        void remove() { m_graph.removeVertex(this); }

    protected:
        GraphVertex(Graph<T> &graph) : m_graph(graph) {}
        Graph<T> &m_graph;
}

template<class T> class Graph
{
    friend class GraphVertex<T>;
    public:
        virtual GraphVertex<T> add(T value) = 0;

    protected: // Or private?
        virtual void removeVertex(GraphVertex<T> *v) = 0;
}

template<class T> class AMGVertex : public GraphVertex<T>
{
    friend class AdjacencyMatrixGraph<T>;

    protected: // Or private?
        AMGVertex(AdjacencyMatrixGraph<T> &graph)
        : GraphVertex<T>(graph) {}
}

template<class T> class AdjacencyMatrixGraph : public Graph<T>
{
    public:
        AMGVertex *add(T value) { ... } // Calls AMGVertex's constructor.

    protected: // Or private?
        void removeVertex(GraphVertex<T> *v) // Only visible from this class and through base class.
        { ... }
}

So, can only be created from , and hence a call to will always call with the correct sub-class as parameter.

It is however still possible to circumvent this, simply by creating a new vertex type with a as . This is because the friendship from vertex to graph is in the abstract base-class.

So a 100% type-safe solution is (at least from what I've gathered) not possible.

In Java I believe similar results can be achieved with nested classes (to overcome visibility limitations).

Thank you for the replies! If someone has a better solution, let us know.