Design Patterns – Best Practices for Manager Type Classes

abstractiondesign-patternsobject-oriented

I have a class that I usually end up calling XManager. This class usually acts a dispatcher. Where it will read a config and do what the config says.

Assuming that I have the following class structure:

-Manger
 | - Phases
   | - PhaseX implements Phase { void run(); }
   | - PhaseY implements Phase { void run(); }
   | - PhaseZ implements Phase { void run(); }
 PhaseManager

In PhaseManager I have some code that looks like:

class PhaseManager {
    private Set<Phase> phases;

    public PhaseManager(Config config) {
        // Use config to instantiate all enabled phases, adding them to phases.
    }

    public void runPhases() {
        for(Phase p : phases) {
            p.run();
        }
    }
}

And thus in my main.java I'd have something like:

PhaseManager manager = new PhaseManager(config);
manager.runPhases();

But I'm convinced there is a better way. And after reading many of the design patterns I cannot figure out exactly to which design pattern this best fits.

It looks like it could be callback, but not really; as there is no action that occurs to initiate this, it just has to happen.

It could be command, but it seems like command is a bit overkill for this approach.

Best Answer

I think the same can (and likely should) be expressed cleaner using the builder pattern.

Result result = InitialPhase.fromConfig(config)
                            .phase1(...)
                            .phase2(...)
                            // ...
                            .build();

Each .phaseN() method may return a class that only allows to invoke the correct next phase(s). (In the "PhaseManager" design it is possible to run the phases in arbitrary order.) Each .phaseN(...) may accept whatever phase-specific parameters there may be.

The final .build() makes the resulting object from a phase object. If the subject area permits, several phases can provide a .build() method, allowing for different build paths.

Related Solutions

Java – Proper OO design for State and Command

Don't get too caught up on the State Pattern. This has a specific usage which I don't think necessarily applies in your game, at least not when you are manipulating the state of play.

Take, for example, a drawing application. In this case, the button pressed in the toolbar affects the way the drawing panel reacts to certain stimuli -- in this case, you don't want the application to know what it is going to do, you just want it to pass the stimulus to the State object and let it figure out what to do.

So, the rectangle drawing button is down, the application holds a RectangleDrawingState from which it can request a mouse-over pointer type or a mouse-down action or whatever. If you press the elipse-drawing button then that control switches out the RectangleDrawingState for an ElipseDrawingState and the application continues to ask for a mouse-over pointer type and a mouse-down action and gets completely different responses.

This is the kind of situation that makes for a good use-case for the State Pattern.

Now you may want this in your turn-based strategy game, to handle whether the attack button is pressed or the gather resources button is pressed. But you should handle the state of the game differently.

The state of the game should be handled as a single mutable object, which is manipulated at the end of each action. This object needs to be serializable in some form.

What you should do then is get a Command object by whatever means necessary and act on the mutable state-of-play object (it might be that your immutable State object, which depends on the action selected at any given time, returns a command which can act on the state-of-play object, for example).

Java Design Patterns – Strategy with Fields Acceptability

I would argue that each instance should remain stateless once it is constructed, i.e., it should not maintain extra state across invocations that changes based on the parameters. A classic example is a tax calculator.

interface TaxCalculator {
    /**
     * Calculates the tax for the given purchase price and shipping charges.
     * All values are in pennies to avoid rounding.
     *
     * @param subtotal total price of all items ordered
     * @param shipping cost of shipping the order
     * @return calculated tax
     */
    int calculate(int subtotal, int shipping);
}

class NoTax implements TaxCalculator {
    public int calculate(int subtotal, int shipping) {
        return 0;
    }
}

class FixedPercentOfSubtotal implements TaxCalculator {
    private final int ratePercent;

    public FixedPercentOfSubtotal(int ratePercent) {
        this.ratePercent = ratePercent;
    }

    public int calculate(int subtotal, int shipping) {
        return subtotal * ratePercent / 100;
    }
}

While FixedPercentOfSubtotal has a member (state), it's provided at construction time and never changes. You could store one instance per state, making them quasi-singletons.

Update

Neither the Wikipedia article nor this Strategy Pattern page make any stipulation that implementations should not maintain state across calls. It's less common because strategies are designed to be interchangeable and pluggable at runtime, but I wouldn't rule it out.

However, that you needed to add a new method to enable that one strategy implementation is a red flag. Other implementations may not need it. Will you define it in the interface anyway? It may make more sense to have the historical-tracking strategy implement RaceListener and add it to the race track instance. This would allow it to be shared among multiple users as a singleton.

Best Answer

Related Solutions

Java – Proper OO design for State and Command

Java Design Patterns – Strategy with Fields Acceptability

Related Topic