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 ?

Silures

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.

Alterative

(2) its considered, I was more interested in compare both methods, thanks – Silures

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

Embosser

Answer 3

Both your methods can be seen as factories. But the second one is a little awkward to use:

var school = new NinjaSchool();
var ninja = school.SpecialtyStudent(NinjaTypes.Flyer);
// to fly you must cast
((FlyingNinja)ninja).Fly();

You've already asked for a flyer, so you shouldn't need to cast. A better option might be to eliminate the enum and ask for the exact ninja that you want:

var flyingNinja = school.FlyingStudent(); // you get a FlyingNinja
flyingNinja.Fly();

Another thing to consider in your design is this: what if you want an invisible ninja that can fly? Or a katana ninja that also throws stars? That will shake up your hierarchy and challenge your belief in inheritance.

Therrien

Answer 4

It's almost a factory method. I would do something like:

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

class Ninja {
String Name;

void jump() {
}

void kickAss() {
}

void useKatanna() {
    System.out.println("nothing happens");
}

void throwStar() {
    System.out.println("nothing happens");
}

void becomeInvisible() {
    System.out.println("nothing happens");
}

void becomeVisible() {
    System.out.println("nothing happens");
}

void fly() {
    System.out.println("nothing happens");
}

void land() {
    System.out.println("nothing happens");
}
}

class StarThrowerNinja extends Ninja {
    void throwStar() {
        System.out.println("throwing star");
    }
}

class NinjaSchool {
    static Ninja create(NinjaTypes WhichType) {
        switch (WhichType) {
        case Generic:
            return new Ninja();
        case StarThrower:
            return new StarThrowerNinja();
        default:
            return null;
        }
    }
}

public class Main {
    public static void main(String[] args) {
        Ninja generic=NinjaSchool.create(NinjaTypes.Generic);
        generic.throwStar();
        Ninja starThrower=NinjaSchool.create(NinjaTypes.StarThrower);
        starThrower.throwStar();
    }
}

Senile