Factory Pattern, Another Pattern or no pattern at all?

Question

I have 2 cases wheter a method can be considered a Factory Design Pattern, this example is in C#, altought, can apply to other programming languages:

enum NinjaTypes {
  Generic,
  Katanna,
  StarThrower,
  Invisible,
  Flyer
}

public class Ninja {
  public string Name { get; set; }
  public void jump() { ... }
  public void kickAss() { ... }
}

public class KatannaNinja: Ninja {
  public void useKatanna() { ... }
}

public class StarNinja: Ninja {
  public void throwStar() { ... }
}

public class InvisibleNinja: Ninja {
  public void becomeInvisible() {...}
  public void becomeVisible() {...}
}

public class FlyNinja: Ninja {
  public void fly() {...}
  public void land() {...}
}

public class NinjaSchool {
  // always return generic type
  public Ninja StandardStudent() {...}
  // may return other types
  public Ninja SpecialityStudent(NinjaTypes WhichType) {...}
}

The method StandardStudent() always return a new object of the same type, the SpecialityStudent(...), may return new objects from different classes that share the same superclass / base type. Both methods are intentionally not virtual.

The question is, are both methods "Factory Design Pattern" ?

My guess is that SpecialityStudent(...) is, but StandardStudent() is not. If the second is not, can be considered another design pattern ?

Answer 1

I don't think that nor a FactoryMethod`nor AbstractFactory patterns forbid the user to use a parameter to specify a type to the creator method. Anyway you should consider at least 2 things in your design:

1. Factory methods are useful to keep the client unaware of the concrete type of the created object. From my point of view isn't wrong to specify explicitly the type of object to be created, but pay attention to not put too much knowledge on the client classes to be able to construct objects through the factory.
2. Both your factory methods return a Ninja object, but some of your ninjas extended class declare additional methods, which client is unaware of. If your client need to use those methods explicitly then maybe you have to make some consideration on your design.

Answer 2

I think this actually looks like an Anti-Pattern. There's really nothing to stop a consumer of this code to just instantiate the specialty ninjas directly. What benefit is there to using the Ninja School? I think the whole point of the Factory pattern is to encapsulate the process of instantiating an object so that you can hide the details from the consumer. Any time you make a change to the "creation" logic, it doesn't break anyone's code. And it just looks like a bad idea to have all the types in an enum. I don't have a concrete reason to back up this claim other than, "it feels wrong".

After reviewing the Abstract Factory pattern, I can see how you could go about turning this into an Abstract Factory, but I don't see the benefit given the semantics of your objects. I think that if you want to have a Ninja factory, you'd have to make the individual constructors protected or internal, so they can't be called directly by consumer code