Refactoring Day 19 : Extract Factory Class

Todays refactoring was first coined by the GangOfFour and has many resources on the web that have different usages of this pattern. Two different aims of the factory pattern can be found on the GoF website here and here.

Often in code some involved setup of objects is required in order to get them into a state where we can begin working with them. Uusally this setup is nothing more than creating a new instance of the object and working with it in whatever manner we need. Sometimes however the creation requirements of this object may grow and clouds the original code that was used to create the object. This is where a Factory class comes into play. For a full description of the factory pattern you can read more here. On the complex end of the factory pattern is for creating families of objects using Abstract Factory. Our usage is on the basic end where we have one factory class creating one specific instance for us. Take a look at the code before:

   1: public class PoliceCarController

   2: {

   3:     public PoliceCar New(int mileage, bool serviceRequired)

   4:     {

   5:         PoliceCar policeCar = new PoliceCar();

   6:         policeCar.ServiceRequired = serviceRequired;

   7:         policeCar.Mileage = mileage;

   8:  

   9:         return policeCar;

  10:     }

  11: }

 

As we can see, the new action is responsible for creating a PoliceCar and then setting some initial properties on the police car depending on some external input. This works fine for simple setup, but over time this can grow and the burden of creating the police car is put on the controller which isn’t really something that the controller should be tasked with. In this instance we can extract our creation code and place in a Factory class that has the distinct responsibility of create instances of PoliceCar’s

   1: public interface IPoliceCarFactory

   2: {

   3:     PoliceCar Create(int mileage, bool serviceRequired);

   4: }

   5:  

   6: public class PoliceCarFactory : IPoliceCarFactory

   7: {

   8:     public PoliceCar Create(int mileage, bool serviceRequired)

   9:     {

  10:         PoliceCar policeCar = new PoliceCar();

  11:         policeCar.ReadForService = serviceRequired;

  12:         policeCar.Mileage = mileage;

  13:         return policeCar;

  14:     }

  15: }

  16:  

  17: public class PoliceCarController

  18: {

  19:     public IPoliceCarFactory PoliceCarFactory { get; set; }

  20:  

  21:     public PoliceCarController(IPoliceCarFactory policeCarFactory)

  22:     {

  23:         PoliceCarFactory = policeCarFactory;

  24:     }

  25:  

  26:     public PoliceCar New(int mileage, bool serviceRequired)

  27:     {

  28:         return PoliceCarFactory.Create(mileage, serviceRequired);

  29:     }

  30: }

 

Now that we have the creation logic put off to a factory, we can add to that one class that is tasked with creating instances for us without the worry of missing something during setup or duplicating code.

 

This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Sean Chambers

I am a Senior software developer from Palm Coast, Florida. An advocate of Domain Driven Design, Behavior Driven Development, creator of FluentMigrator and community activist. I am married to my beautiful wife Erin and am the proud father of two wonderful children. I currently reside at ACI, a local insurance industry/mortgage software company that excels in creating solutions using Agile methodologies.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Decker

    Your sample shows a creation method moving from a Controller class to a factory class. Shouldn’t the example more properly show how how a factory replaces a class’s constructor?