在C ++接口中声明模板函数？

Question

For the sake of a demonstration imagine that I have some animal classes, each derived from an 'animal' class, each 'knowing' what type they are, and each having some sort of unique ability:

enum class animal_type { antelope, bear, cat };

class animal
{
};

class antelope : public animal
{
public:
    static const animal_type type = animal_type::antelope;
    void run() { std::cout << "antelope runs\n"; };
};

class bear : public animal
{
public:
    static const animal_type type = animal_type::bear;
    void roar() { std::cout << "bear roars\n"; };
};

class cat : public animal
{
public:
    static const animal_type type = animal_type::cat;
    void meow() { std::cout << "cat meows\n"; };
};

Now, I want to be able to retrieve animals based on their type:

class animal_getter
{
public:
    animal& get(animal_type t)
    {
        static antelope s_antelope;
        static bear s_bear;
        static cat s_cat;

        switch (t)
        {
            case animal_type::antelope:
                return s_antelope;

            case animal_type::bear:
                return s_bear;

            case animal_type::cat:
                return s_cat;
        }
    }
};

And finally, it would be nice to get the actual type of animal back, to make the calling syntax nicer:

template<typename T>
T& get()
{
    return static_cast<T&>(get(T::type));
}

Now I can write something like this:

animal_getter ag;
ag.get<antelope>().run();

rather than the wordier:

animal_getter ag;
static_cast<antelope&>(ag.get(animal_type::antelope)).run();

I hope there's nothing too unreasonable about that. But now I want to be able to unit test getting an animal, so ideally it will be possible to fake the animal_getter class (imagine the actual implementation accesses a database or something which you don't want in a unit test, hence the fake). So it would be nice to define an interface for 'animal getter' classes, and then create a fake that implements the interface. And here's the problem, can this interface be written ? This isn't going to compile:

struct IAnimalGetter
{
    virtual template<typename T> T& get() = 0;
};

Is it possible to rescue this idea or can template functions never be declared a virtual for the purpose of defining an interface that includes them?

If the idea is a non-starter, at what point did this start to go wrong? Was it when the template function was written which does its own casting? Should I have stopped at something which returns an animal object and then have the caller be responsible for the cast?

Answer 1

Templates and casts and type tags don't seem to serve any useful purpose in the declared use case (getting an animal and then immediately exploiting its unique characteristics).

antelope& get_antelope();
bear& get_bear();
cat& get_cat();

This is all that's needed.

get_antelope().run();
get_cat().meow();

These functions can be standalone or member, virtual if desired. You need one function per returned type. This is not very different from, and in some ways superior to, one case in a switch statement per returned type.

If, for some yet unspecified reason, you do need a function template, you can define one based on plain functions.

 template <class A>
 A& get_animal();

 template<> antelope& get_animal<antelope>() { return get_antelope(); }
 template<> bear& get_animal<bear>() { return get_bear(); }
 template<> cat& get_animal<cat>() { return get_cat(); }

Answer 2

Virtual template functions are not allowed, but your template function has no logic, so in this case I would use:

struct IAnimalGetter
{
    virtual animal& get(animal_type t) = 0;

    template<typename T>
    T& get()
    {
      return static_cast<T&>(get(T::type));
    }
};

And:

class animal_getter : public IAnimalGetter
{
public:
    animal& get(animal_type t)
    {
        // implementation
    }
};

class mock_animal_getter : public IAnimalGetter
{
public:
    animal& get(animal_type t)
    {
        // mock implementation
    }
};

Answer 3

The use of casting kind of defeats the point of using templates here. Its not really clear to me what the getter class is for. Its clear its for holding some static instances of some pre-determined types, but its not clear why its a single class handling all the types. I can't see that you gain much as it doesn't have much code in and you have to specify the type in the call anyway. The switch statement is a potential bug, if you add a new animal type it will still compile but the new type wont be handled in the switch and you get a run time error.

If you don't need static instances, just construct the correct type.

If you do need them then consider whether they should be managed by that type (ie bear has a method to get the bear instance). Another option (as has already been pointed out) is to expose the static instances of each type your getter holds.

If you don't want to manage the static instances in the related classes, consider having separate getters:

template<typename T>
struct IGetter
{
    virtual T Get() =0;
};

template<typename T>
struct RealGetter : public IGetter<T>
{
    static T item;
    virtual T Get()
    {
         return item;
    }
 };

template<typename T>
struct MockGetter : public IGetter<T>
{

   virtual T Get()
   {
     // some mock implementation
   }
};