Question

My question is more or less identical to the one at Need a design pattern to remove enums and switch statement in object creation However I don’t see that the abstract factory pattern suits well here.

I’m currently planning the refactoring/reimplementation of some existing DAL/ORM mixture library. Somewhere in the existing code there is code that looks like this:

class Base
{
  static Base * create(struct Databasevalues dbValues)
  {
    switch(dbValues.ObjectType)
    {
    case typeA:
      return new DerivedA(dbValues);
      break;
    case typeB:
      return new DerivedB(dbValues);
      break;
    }
  }
}

class DerivedA : public Base
{
  // ...
}

class DerivedB : public Base
{
  // ...
}

So the library responsible for database communication populates a struct with all information about the database entity and then the above create() method is called to actually create the corresponding object in the ORM.
But I don’t like the idea of a base class knowing of all its derived classes and I don’t like the switch statement either. I also would like to avoid creating another class just for the purpose of creating those Objects. What do you think about the current approach? How would you implement this functionality?

Answer 1

No matter what you do, you’ll need either switch-case or some other construct that will just hide similar logic.

What you can and should do, however, is remove the create method from your Base – you’re totally correct it shouldn’t be aware of it’s derived ones. This logic belongs to another entity, such as factory or controller.