The
factory method pattern is a creational software design pattern that encapsulates how to construct a dependency into method. The method could return any number of concrete implementations. However the consuming code only accesses the dependency through an interface or abstract base class. This pattern is useful when there is distinct logic to return one concrete class over another. It is also an effective pattern when
working with legacy code, as it is easier to introduce a new method than a whole new interface.
The essence of the pattern is simply a virtual method that contains logic to create and/or return an instance of a dependency used by the consuming class.
Here's an example using the pattern to allow for unit testing substitution.
namespace FactoryMethodDemo
{
public class ProductMaintenance
{
public void EditProduct(int id, string name, decimal price)
{
var dataAccess = this.CreateDataAccess();
var product = dataAccess.GetProductById(id);
product.Name = name;
product.Price = price;
dataAccess.Save(product);
}
public virtual DataAccessLayer CreateDataAccess()
{
return new DataAccessLayer();
}
}
public class DataAccessLayer
{
public virtual Product GetProductById(int id)
{
// Expensive database call...
// Omitted
throw new NotImplementedException();
}
public virtual void Save(Product product)
{
// Omitted
throw new NotImplementedException();
}
}
public class Product
{
public string Name { get; set; }
public int Id { get; set; }
public decimal Price { get; set; }
}
}
In this example the CreateDataAccess method is the factory method pattern. Granted this is a very simple example, the method could contain a great deal of initialisation logic, or logic to determine which DataAccessLayer to return if there is more than one data store. This could be useful when the database is partitioned (sharded) across multiple servers.
Things to note:
- Always make factory methods virtual. This always for testing as well as other variations in other sub-classes.
- Prefer to name the method with clear indicators about how it behaves. I have chosen the word "Create" to inform consumers that each call to the method will create a new DataAccessLayer instance.
- Prefer to make the return type an interface. This may not be feasible with legacy code, hence my demo here uses virtual methods. This is easier to introduce into an existing code base than an interface. Although if its possible introduce an interface.
Here's the test code to test the ProductMaintenance class.
namespace TestProject1
{
using FactoryMethodDemo;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Rhino.Mocks;
public class ProductMaintenanceTestHarness : ProductMaintenance
{
private DataAccessLayer mock;
public ProductMaintenanceTestHarness(DataAccessLayer mockDataAccessLayer)
{
this.mock = mockDataAccessLayer;
}
public override DataAccessLayer CreateDataAccess()
{
return this.mock;
}
}
[TestClass]
public class ProductMaintenanceTest
{
public TestContext TestContext { get; set; }
[TestMethod]
public void EditProductTest()
{
var productTestData = new Product
{
Id = 1,
Name = "Bar",
Price = 89.95M,
};
var mockDataAccessLayer = MockRepository.GenerateMock<DataAccessLayer>(); // Able to mock because methods are virtual
mockDataAccessLayer.Expect(m => m.GetProductById(1)).Return(productTestData);
mockDataAccessLayer.Expect(m => m.Save(productTestData));
var subject = new ProductMaintenanceTestHarness(mockDataAccessLayer);
subject.EditProduct(1, "Foo", 99.99M);
mockDataAccessLayer.VerifyAllExpectations();
Assert.AreEqual(99.99M, productTestData.Price);
}
}
}
