Design Problem - Whether to use Templates, Inheritance, or Nothing

Hey all,

Hope you're doing well.

I have a bit of a design problem that I can't quite figure out how to pull off. Essentially, I have a graph (happens to be directed, but that's not terribly important) of types of widgets. An edge in the graph represents that we know how to turn a widget of one type into a widget of another type, and it should be accompanied by the converter to do so. Each type of widget looks like:

Code:

---

template <typename WIDGET_TEST>
class WidgetInterface
{
public:
    virtual bool verify(const WIDGET_TEST& wt) const = 0;
    virtual float getAccuracy(const WIDGET_TEST& wt) const = 0;
};

---

Here's a sample implementation:

Code:

---

class FooWidgetTest;

class FooWidget : WidgetInterface<FooWidgetTest>
{
    virtual bool verify(const FooWidgetTest& wt) const;
    virtual float getAccuracy(const FooWidgetTest& wt) const;

protected:

    // various data structures - say a graph, an int, and a Ferrari
};

---

And here would be the converters.

Code:

---

template <typename WidgetA, typename WidgetB>
class Converter
{

public:
    virtual WidgetB convert(const WidgetA& aw) = 0;
    virtual WidgetATest reverseTest(const WidgetBTest& wbt) = 0;

    // not sure how to get it to work, but ideally would like to pull
    // the types of WidgetATest and WidgetBTest from WidgetA and WidgetB
};

class FooToBazConverter : Converter<FooWidget, BazWidget>
{
    virtual BazWidget convert(const FooWidget& aw);
    virtual FooWidgetTest reverseTest(const BazWidgetTest& wbt);
};

---

From this point, what I want to be able to do is, given an instance of a widget of one type and a target type, find the shortest path in the graph of conversions, then run through all of the converters to end up with that widget instance converted to another widget type. However, I see several problems with this.

1. WidgetInterface doesn't really help much if each Widget implementation uses a different template param, because then as far as I know, we can't store these in the same data structure, so I don't know what type to make the vertices in the graph. I could of course eliminate the template part, and make them all generic parameters (FooWidget inherits AbstractWidget, and AbstractWidget's interface uses AbstractWidgetTests), but then all of the subclasses have to manually cast their arguments whenever they receive them.

2. I have the same problem for the converters; I wouldn't know what type of structure to make the edges in the graph.

Does anybody have any advice on how to accomplish this problem? At this point I'm guessing this is NOT an appropriate use of templates, or even inheritance, but it also seems clunky to just implement all of these as standalone types if they have the same signatures just with different types. Thanks very much in advance.

--Fortress

P.S. I was planning to use the Boost graph classes, as I've never tried them before, so any advice specific to those would be fantastic.

What exactly is WIDGET_TEST. What do these parameters do

Quote:

---

WidgetInterface doesn't really help much if each Widget implementation uses a different template param, because then as far as I know, we can't store these in the same data structure

---

I had a problem when initially designing my templated image classes that I couldn't create containers of pointers to them, for the reasons you describe. My solution was to create an abstract base class that they all inherited from, containing all of the functionality that didn't rely on knowing the actual image format. Maybe a similar solution could work for you?

Code:

---

Image
 ^
Image_Template
 ^          ^
Image_Grey Image_Rgb

---

@souldog

I'll put it in context. The WIDGET_TEST is a certificate and the Widget types are mathematical/computational problems. The converters reduce one problem type to another, while a certificate is used to verify a given solution (like NP-complete). The WIDGET_TEST doesn't change the widget in any way, but the certificate for each problem does contain different data members.

Thus, given an instance of a problem type, we want to be able to convert it into another type of problem (by traversing the reductions graph) which we may know how to solve, or be better at solving. The solution (certificate) can then be filled out for that problem, converted back through the graph to a solution for the original problem type, and we can check whether the approximation was successful or close to it.

@John

So, if I understand what you're saying, you would put all of the functions with identical parameters in the Image class, and then the template class would contain my functions which are similar but have different types.

If I were to take this approach, how would I call the template-specific functions? Would I pull the Image* from the graph, somehow cast it to the templated type, and call the function? I think I might not know enough about using templates to pull this off, but that sounds like a reasonable approach.

to start of with the widgets. The problem is the WIDGET_TEST parameters.

One solution is to use a base class for these parameters and then introduce an intermediary base class that does the casting for you.

Here is an example which does not do safe casts etc.. but get the idea across

Code:

---

class WidgetTest
{
public:
        virtual ~WidgetTest() = 0;
};

WidgetTest::~WidgetTest(){}

class WidgetInterface
{
public:
        virtual ~WidgetInterface(){}
    virtual bool verify(const WidgetTest& wt) const = 0;
    virtual float getAccuracy(const WidgetTest& wt) const = 0;
};

template<typename WT>
class WidgetTestCast : public WidgetInterface
{
public:
    virtual bool verify(const WidgetTest& wt) const
        {
                return verifyIMPL(static_cast<const WT&>(wt));
        }
    virtual float getAccuracy(const WidgetTest& wt) const
        {
                return getAccuracyIMPL(static_cast<const WT&>(wt));
        }
private:
    virtual bool verifyIMPL(const WT& wt) const = 0;
    virtual float getAccuracyIMPL(const WT& wt) const = 0;
};

class FooWidgetTest : public WidgetTest
{
public:
        FooWidgetTest():
        blah(1)
        {
        }
        virtual ~FooWidgetTest(){}
        int blah;
};

class FooWidget : public WidgetTestCast<FooWidgetTest>
{
private:
    virtual bool verifyIMPL(const FooWidgetTest& wt) const
        {
                std::cout << "verify " << wt.blah << '\n';
                return true;
        }
    virtual float getAccuracyIMPL(const FooWidgetTest& wt) const
        {
                std::cout << "getAccuracy " << wt.blah << '\n';
                return 1.0;
        }
};

---

Now you have a common base class for the widgets to store in a container, but don't have to explicitly cast in the subclasses

Quote:

---

Originally Posted by fortress

If I were to take this approach, how would I call the template-specific functions? Would I pull the Image* from the graph, somehow cast it to the templated type,

---

The 'Visitor Pattern' could be of some help here.

Thanks for your help, everyone.

@souldog

That's definitely a lot cleaner than what I was trying to do. It might be an effective technique for the converters as well.

@JohnW

I didn't think of that, I've never used Visitor to do callbacks on objects of the same type but with different template parameters. I'll look into it.