Java implementation of the Factory Method pattern
This pattern can be difficult to understand outside of an application with many modes of operation. There are two advantages to using the factory patterns: you can swap in different implementations, and you can vary the construction parameters without changing client code.

Where do these advantages shine? Testing! In the case of a game, randomness is a good example. When playing the game for real, you want your monsters to vary their behavior randomly. But when testing, you need to be able to choose from their possible behaviors. The real factory will initialize each monster with a real random number generator, but tests must be able to specify the behavior choices. 

Take this example monster action:

public void chooseCombatAction() {
    if (isAfraid()) {
        return Action.RUN;
    }
    else {
        return Action.ATTACK;
    }
}

private boolean isAfraid() {
    return random.nextInt(10) &gt; 7;
}


To test chooseCombatAction, you need to provide a mock random number generator. But if the constructor creates it, you can't. Instead, have the factory provide it, and create an implementation that takes one with pre-configured values. Now you can give that factory to the root game object that uses the factory to create monsters.


  Style Note: Drop implied modifiers--such as public and abstract on interface members--wherever possible. Every modifier adds context that must be groked.