Question

Good morning,

I inherited some legacy code at work and it is using a rather unusual design pattern. The only reference I could find on the forums to a similar pattern was here. The situation is that the original designer has a generic parent class (not abstract) that has a static factory method which directly references children classes.

Here is a sample of that style of coding, found in several places in the legacy code:

public static LoggerFactory getLoggerFactory(LogType type) {
    switch (type) {
    case LOG4J:
        return Log4JLoggerFactory.getInstance();
    case LOGBACK:
        return LogBackLoggerFactory.getInstance();
    default:
        throw new RuntimeException("No logger factory defined for type " + type);
    }
}

Where Log4JLoggerFactory and LogBackLoggerFactory extend LoggerFactory.

This seems really foreign to me but before I re-factor the code significantly, is there any purpose or benefit to this design pattern (is there even a formal name for it)?

Any thoughts or advice is appreciated. Thanks!

EDIT: After reading Yishai’s response, I thought I would include a link to the Wikipedia article on the Strategy pattern, for easy reference. Thanks to everyone for your responses!

Answer 1

It’s a very standard pattern in Java, and a common way to implement a Strategy pattern. You see it in the standard API all the time (Calendar vs. GregorianCalendar, NumberFormat vs. DecimalFormat and more).

That being said, with Dependency Injection being all the rage, such a pattern might indeed be replaced by a dedicated Factory class with a dedicate Factory interface, but in the absence of a larger design reason, I think the example you give is a perfectly reasonable design choice.