title: Handling derived class creation using mappers in C++
body: <p>I'm reading through Martin Fowler's PoEAA right now on object-relational structural patterns. As a project to do while learning them, I thought I'd build a mini eCommerce system in C++. I'm having trouble figuring out how to return the objects from the mapper.</p>
  
  <p>I have a <code>Product</code> base class, which has derived classes <code>Hat</code> and <code>Shirt</code>. <code>Products</code> have a <code>type</code> member to identify which derived class they are. I also have a <code>ProductMapper</code> class, with derived classes <code>HatMapper</code> and <code>ShirtMapper</code>, all of which implement a bunch of finder methods which let me try and retrieve certain hats and shirts.</p>
  
  <pre><code>class Product
  {
      unsigned long long int id;
      std::string name;
      unsigned int type;
  };
  
  
  // Derived classes don't necessarily have the same members.
  
  class Hat : public Product
  {
      unsigned char fitted;
      unsigned char color;
      unsigned char style;
  };
  
  class Shirt : public Product
  {
      unsigned char size;
  };
  </code></pre>
  
  <p>In the logic part of my application where I'd instantiate these mappers and retrieve products is where I'm having trouble. I can instantiate a <code>HatMapper</code> and pull back <code>Hat</code> objects without any problem, same with a <code>ShirtMapper</code> and <code>Shirt</code> objects. The patterns work great in these cases (in particular I'm using class table inheritance, i.e. one product table with product data, one table for hats with hat-specific data, and one table for shirts with shirt-specific data).</p>
  
  <p>My problem is, what do I do if I want to retrieve all products, both hats and shirts? I can instantiate a <code>ProductMapper</code> and fetch all of the product data, but that seems like the wrong approach since I'd have to loop through all the <code>Products</code> I retrieve and build up <code>Hats</code> and <code>Shirts</code> based on their type in my logic portion of the program. Additionally, I'd have to modify any code that handles the situation this way when I add new product types. Seems bad.</p>
  
  <p>The Fowler book has examples of the mappers with the base mapper using the derived mappers which seems completely wrong to me (have to modify the base mapper every time I add a new product, not great). Here's a quick example of how it's done there:</p>
  
  <pre><code>class ProductMapper
  {
      unsigned long long int productId;
      unsigned long long int productType;
  
      HatMapper * hm;
      ShirtMapper * sm;
  
      Product * FindById(unsigned long long int id)
      {
          // Query database for data.
  
          if (this-&gt;productType == PRODUCT_TYPE_HAT)
          {
              return hm-&gt;FindById(id); // Hat object.
          }
  
          else if (this-&gt;productType == PRODUCT_TYPE_SHIRT)
          {
              return sm-&gt;FindById(id); // Shirt object.
          }
  
          return NULL;
      }
  };
  </code></pre>
  
  <p>Here's how I'd use this in the logic part of my program. Examples of this aren't provided in the book:</p>
  
  <pre><code>ProductMapper * pm = new ProductMapper();
  Product * p = pm-&gt;FindById(1); // It's a Product, but a Hat or Shirt?
  
  // Have to check type since a Product was returned.
  switch (p-&gt;type)
  {
      case PRODUCT_TYPE_HAT:
      {
          Hat * h = (Hat) p;
          break;
      }
  
      // Etc. Modify this every time a new product type is added or removed.
  }
  </code></pre>
  
  <p>This will introduce circular dependencies. Additionally, assuming I somehow eliminate the circular dependencies, the result of the <code>HatMapper</code> and <code>ShirtMapper</code> classes are <code>Hat</code> objects and <code>Shirt</code> objects. Thus when I return from the <code>ProductMapper</code>, I'll be downcasting, so I'd have to again manipulate the result in my logic, which again introduces the issue of modifying code when I introduce new product types.</p>
  
  <p>I'm at a loss for what to do. In a perfect world, I'd like to have a <code>Product</code> class and a <code>ProductMapper</code> class, both of which I can extend quickly, introducing new product types without having to modify existing code (at least too much).</p>
  
  <p>I would like to be able to use these patterns from PoEAA, they do seem nice and useful, but I'm not sure if it's just something I can't do in C++ or I'm missing something that's preventing me from doing it. Alternative patterns and approaches are also really welcomed.</p>