Is this Factory Method creation pattern?

Question

I have been using factory method creation pattern for awhile now. I was just recently told that this:

public static class ScheduleTypeFactory {     public static IScheduleItem GetScheduleItem(ScheduleTypeEnum scheduleType)     {         IScheduleItem scheduleItem = null;          switch (scheduleType)         {             case ScheduleTypeEnum.CableOnDemandScheduleTypeID:                 {                     scheduleItem = new VODScheduleItem();                     break;                 }             case ScheduleTypeEnum.BroadbandScheduleTypeID:                 {                     scheduleItem = new VODScheduleItem();                     break;                 }             case ScheduleTypeEnum.LinearCableScheduleTypeID:                 {                     scheduleItem = new LinearScheduleItem();                     break;                 }             case ScheduleTypeEnum.MobileLinearScheduleTypeID:                 {                     scheduleItem = new LinearScheduleItem();                     break;                 }         }          return scheduleItem;     } } 

is not a factory method creation pattern by my "Tech" lead without telling me why or giving me her interpretation. I kindly asked for an explanation and she told me she didn't have time. I was told to just rename it. If I am wrong, then I will no doubt accept that I have implemented this incorrectly for years. Is this how YOU would implement the factory method creation pattern? Thanks in advance.

Answer 1

I would agree to call the method a "Factory Method", though the design is not strictly a "Factory Method Pattern".
Here is a key point (from Wikipedia):

...The Factory method lets a class defer instantiation to subclasses."

Since your class is static and method static (hence non-virtual), there is no "deferring" possible.

Conceptually, notice also, that this implementation, though provides encapsulation, does not decouple/delay any decision.

Having said that, same Wikipedia article does present this schema as a variant of the "Factory Method Pattern".

Summary of the Summary: In my opinion this snippet is not a proper implementation of the "Factory Method OO Design Pattern", since it does not satisfy "a class defer instantiation to subclasses." Though, personally I would freely refer to this solution as "factory method".

To make it real factory method pattern, you need to allow the method to be overridden by subclasses. I.e. factory class (ScheduleTypeFactory) needs to be extensible (i.e. non-static), and GetScheduleItem needs to be virtual.

Answer 2

Sure looks like the factory pattern to me. I don't see anything wrong with your implementation.

From Factory method pattern:

The essence of the Factory Pattern is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

This is exactly what you are doing.

As a side note: a good rule of thumb is that whenever someone tells you something and is unable or unwilling to provide a rationale for their statement, there is a good chance they are unqualified to make the statement at all.