Factory pattern love

Where I love the factory pattern.

A factory aware of its surroundings

The Factory pattern is one I’ve grown fond of recently and that solves the “problem” of handling user options in a WordPress project (or wherever persisted UI-managed options are involved).
I say “aware of its surroundings” to mean that the factory will take those options into account when building and returning an instance of a requested object; an example of this might be, in the case of the schedule class that’s being built, this factory class:

class WPSchedule_Time_Factory implements WPSchedule_Interface_FactoryInterface {

    public static function make( $hook, array $args = null ) {
        if ( ! is_string( $hook ) ) {
            throw new Exception( 'Hook name must be a string' );
        }

        $timeSlug = get_option( $hook . '_schedule_time', 'now' );
        $timeSlug = is_string( $timeSlug ) ? $timeSlug : 'now';

        $instance = null;

        switch ( $timeSlug ) {
            case '8pm':
                $instance = new WPSchedule_Time_EightPM();
                break;
            case '8am':
                $instance = new WPSchedule_Time_EightAM();
                break;
            case 'now':
                $instance = new WPSchedule_Time_Now();
                break;
            default:
                $instance = new WPSchedule_Time_Now();
                break;
        }

        return $instance;
    }
}

what the class is doing is trying to fetch an option from the database using the get_option function to instantiate and return the proper time object.
The idea behind the class is to have a UI control that will save an option like

set_option('my_hook_schedule_time', '8am');

to asynchronously fetch the option later using

$time = WPSchedule_Time_TimeFactory::make('my_hook');

The interval factory

Not a revolution in terms of code a similar factory is built for the interval

class WPSchedule_Interval_Factory implements WPSchedule_Interface_FactoryInterface {

    public static function make( $hook, array $args = null ) {
        if ( ! is_string( $hook ) ) {
            throw new Exception( 'Hook name must be a string' );
        }

        $intervalSlug = get_option( $hook . '_schedule_interval', '1m' );
        $intervalSlug = is_string( $intervalSlug ) ? $intervalSlug : '1m';

        $instance = null;

        switch ( $intervalSlug ) {
            case '12h':
                $instance = new WPSchedule_Interval_TwelveHours();
                break;
            case '1h':
                $instance = new WPSchedule_Interval_OneHour();
                break;
            case '1m':
                $instance = new WPSchedule_Interval_OneMinute();
                break;
            default:
                $instance = new WPSchedule_Interval_OneMinute();
                break;
        }

        return $instance;
    }
}

And once again the use flow would be to have a UI control setting an option somewhere

set_option('my_hook_schedule_interval', '12h');

to fetch it later using the factory make method

$interval = WPSchedule_Interval_Factory::make('my_hook');

Next

I’m taking a very slow approach to testing and breaking my own rules, for the sake of clarity here, by writing code before tests for the two factory classes above: I will test them using function-mocker next to cover the edge cases, decide when to stop testing them and instead refactor the classes.
The code ending this post is on GitHub tagged 0.1.5.

I appreciate your input