Implementing a Factory that uses Specifications to determine which type of object to create

Question

This is mainly a thought experiment. So this all is sample code. My goal was to use the specification pattern to eliminate giant blocks of conditional code inside a factory. So with this sample I have a StatusData object that I want to get an implementation of IStatusUpdate that is appropriate for for it.

I have the following set of tests:

    [TestMethod]
    public void Factory_Interface_Should_Return_IStatusUpdate()
    {
      var factory = MockRepository.GenerateMock<IUpdateFactory<StatusData>>();
      var obj = MockRepository.GenerateStub<IStatusUpdate>();

      var data = new StatusData();
      factory.Stub(x => x.Get(data)).Return(obj);

      var item = factory.Get(data);

      Assert.IsInstanceOfType(item, typeof(IStatusUpdate));
    }

    [TestMethod]
    public void StatusUpdateFactory_Should_Return_IStatusUpdate()
    {
      var factory = new StatusUpdateFactory();
      var data = new StatusData();

      var item = factory.Get(data);

      Assert.IsInstanceOfType(item, typeof(IStatusUpdate));   
    }

    [TestMethod]
    public void StatusUpdateFactory_Should_Return_NewStatusUpdate_When_Status_Is_New()
    {
      var data = new StatusData(Status.New);
      var factory = new StatusUpdateFactory();

      var item = factory.Get(data);

      Assert.IsInstanceOfType(item, typeof(NewStatusUpdate));
    }

My Factory implementation so far looks like this:

public class StatusUpdateFactory:IUpdateFactory<StatusData>
  {
    public IStatusUpdate Get(StatusData item)
    {
      IList<ISpecification<StatusData>> specs = GetSpecifications();

      foreach (var spec in specs)
      {
        if (spec.IsSatisfiedBy(item))
          //how do I do this?
           return new NewStatusUpdate();

      }
      return null;
    }

    private IList<ISpecification<StatusData>> GetSpecifications()
    {
      var returnList = new List<ISpecification<StatusData>>();
      var specTypes = this.GetType().Assembly.GetTypes()
                        .Where(z => z.IsInstanceOfType(typeof(ISpecification<StatusData>)))
                        .ToList();


      specTypes.ForEach(x => returnList.Add(Activator.CreateInstance(x) as ISpecification<StatusData>));

      return returnList;

    }
  }

Where I am falling down is once I have discovered a specification that is satisfied by the status object, how do I map that specification to a type that implements IStatusUpdate.. I am stumped.

Someone rightly suggested that I need a mapping of specifications to IStatusUpdate implementers. This mapping seems to be a responsibility of the factory, hanging it off the specification smells like a violation of SRP. I could create a Mapper class that has that responsibility but that doesn't seem very generic and also raises the question how do I map the mapper to the spec.

There is still one little leap here I am missing.

Answer 1

If I have understood correctly, you want, given an object implementing ISpecification you want an object implementing IStatusUpdate?

In your sample none of these types are defined, so I don't know if there is any relationship between them you could use.

But likely you will either need need some factory to hold the code, or a method ISpecification.GetUpdate() to do the object creation.

Answer 2

So I'm assuming we're really focusing on this set of lines:

if (spec.IsSatisfiedBy(item))
          return new NewStatusUpdate();

and I assume you're asking how in this current form this can be done. It seems like item should support like

interface ISpecSupport<T>
{
    bool ItemSpecsContain(ISpecification<T> spec);
}

Then the spec.IsSatisfiedBy method can take in this interface type and run the method.

In other words I guess I'm saying that the object should carry some sort of description of what it is (in terms of specs). I'm guessing that's a list of some sort but I'm not sure. I'm sure you've probably thought of this so if you can add anything that'd be helpful.

Also, instead of the above maybe you could rearrange it like so:

if (item.Satisfies(spec))
    return new NewStatusUpdate();

Then this way you don't have to use the much maligned visitor pattern (I think that's what I was describing before this). It's more direct since the item seems like it would own the specs and this way you're allowing the item to decide if it meets the spec.

If you don't want this logic held within the object (which I would understand) AND you are using a property bag of some sort (or you're cool with reflection) you could dig into the details of the object with an independent spec validator. Actually, an independent validator might not be a bad idea to begin with. I'm not so sure that the ability to know if a spec matches an item is a responsibility that should remain with an individual spec.