Question

Suppose that I have two sets of associated types, for example Animals and their Offspring:

/* Animal types */
struct Animal
{
  virtual string getType() const = 0;
};

struct Cat : public Animal
{
  virtual string getType() const { return "Cat"; }
};

struct Dog : public Animal
{
  virtual string getType() const { return "Dog"; }
};


/* Offspring types */
struct Offspring
{
  virtual string getType() const = 0;
};

struct Kitten : public Offspring
{
  virtual string getType() const { return "Kitten"; }
};

struct Puppy : public Offspring
{
  virtual string getType() const { return "Puppy"; }
};

I am trying to implement a factory which, given an Animal will return an object of the associated Offspring type (e.g. if the Animal is in fact a Dog, the factory will return a Puppy).

My first attempt at implementing such a factory looks like this:

// First attempt at OffspringFactory
class OffspringFactory1
{
  static Offspring* createKitten() { return new Kitten(); }
  static Offspring* createPuppy()  { return new Puppy();  }

public:
  // Create an Offspring according to the Animal type
  static Offspring* getOffspring(const Animal& a)
  {
    // Static mapping of Animal types to Offspring factory functions
    static map<string, Offspring* (*)()> factoryMap;
    if (factoryMap.empty())
    {
      factoryMap["Dog"] = &createPuppy;
      factoryMap["Cat"] = &createKitten;
    }

    // Lookup our Offspring factory function
    map<string, Offspring* (*)()>::const_iterator fnIt = factoryMap.find(a.getType());
    if (fnIt != factoryMap.end())
      return fnIt->second();
    else
      throw "Bad animal type";
  }
};

It works fine, but I’ve resorted to a string-based mapping rather than something purely type-based. In trying to move towards a more type-based implementation I arrived at this:

// Second attempt at OffspringFactory
class OffspringFactory2
{
  // Mapping Animal types to Offspring types
  template<typename TAnimal> struct OffspringMapper;

  template<>
  struct OffspringMapper<Cat> {
    typedef Kitten offspring_type;
  };

  template<>
  struct OffspringMapper<Dog> {
    typedef Puppy offspring_type;
  };

  // Factory method
  template<typename TAnimal>
    static Offspring* create() { return new OffspringMapper<TAnimal>::offspring_type(); }

public:
  // Create an Offspring according to the Animal type
  static Offspring* getOffspring(const Animal& a)
  {
    // Static mapping of Animal type strings to Offspring factory functions
    static map<string, Offspring* (*)()> factoryMap;
    if (factoryMap.empty())
    {
      factoryMap["Dog"] = &create<Dog>;
      factoryMap["Cat"] = &create<Cat>;
    }

    // Lookup our Offspring factory function
    map<string, Offspring* (*)()>::const_iterator fnIt = factoryMap.find(a.getType());
    if (fnIt != factoryMap.end())
      return fnIt->second();
    else
      throw "Bad animal type";
  }
};

Frankly, I’m not sure I’ve improved anything here: I still have my string mapping, along with quite a few more lines of less readable code…

Is there any merit in the second implementation over the first, and is there any way I can get rid of that map?

Answer 1

This looks like a classic case of double-dispatch. One pattern for solving this problem in C++ is the Visitor pattern.

class Offspring;
class OffspringFactory;

class Animal {
public:
    // ... rest of Animal class ...

    virtual Offspring* acceptOffspringFactory(OffspringFactory& factory)const = 0;
};

class OffspringFactory {
public:
    Offspring* createCatOffspring()
    {
        return new Kitten;
    }

    // ... one createXOffspring() for each type of Animal

    Offspring* getOffspring(const Animal& a)
    {
        return a.acceptOffspringFactory(*this);
    }
};

Offspring* Cat::acceptOffspringFactory(OffspringFactory& factory)const
{
    return factory.createCatOffspring();
}

// etc for rest of Animal classes

Now that I look at your problem again, you don’t indicate that the factory is abstract, so really you could do away with the factory in entirety if you can add a method like @MooingDuck mentioned.