Discussion on: An IoC pattern to avoid repetitive if statements

[Bertil Muth]

Hi Tomaz.
Thanks for the article, I liked reading it. You do a great job getting your point across.

If you are open to some improvement suggestions, here are some.

The code as you provide it doesn't compile. This may be confusing to Java newcomers.
The DataHandler interface uses the IncomingData and ProcessedData types in the handleData() method, but the BrazilianDataHandler uses String types for the same method.
All but the first occurence of the DataHandlerFactory class miss the Assert class - at least a comment would be helpful there (like // rest of class omitted for brevity).

Concerning the pattern itself: the factory could be simplified to take any number of DataHandler arguments, like so:

public class DataHandlerFactory {

    private final List<DataHandler> dataHandlerList;

    public DataHandlerFactory(DataHandler... dataHandlers) {
        dataHandlerList = Arrays.asList(dataHandlers);
    }

    public DataHandler obtainDataHandlerFor(String url) {
        Assert.notNull(url, () -> "Url is null!");
        return dataHandlerList
                .stream()
                .filter(handler -> handler.shouldHandle(url))
                .findFirst()
                .orElseThrow(() -> new IllegalArgumentException("Url not supported!"));

    // You also check if more than one instance has been found by using List.size() on the list returned by a collect(toList()) at the end of the stream call.
    }

    private static class Assert {
        public static void notNull(Object input, Supplier<String> errorMessageSupplier) {
            if (input == null) throw new IllegalArgumentException(errorMessageSupplier.get());
        }
    }
}

That way, you wouldn't even need to adapt it when a new handler is introduced.

[Tomaz Lemos]

Hi Bertil,

Thanks for your feedback! The String input and return types where wrong leftovers from a earlier version, I have fixed it, and also put the comment where the Assert class is missing.

By saying the code doesn’t compile, you mean you think I should provide implementation to all classes, such as the handlers, IncomingData and ProcessingData? Perhaps that would introduce too much not important code? Or at least I should make clear I’m not providing those classes.

The constructor idea is indeed better, I’ll change it as soon as I get to my computer. In my original post I used Spring for DI and received a List in the constructor, but a fellow DEV correctly suggested I should make the examples framework agnostic, and I missed this improvement.

Thanks a lot for your feedback!

[Bertil Muth]

Hi Tomaz.

By saying the code doesn’t compile, I really just meant the types and the missing Assert class (as described in my comment).

For me, the incompleteness is less of a problem.

Thanks for reacting so quickly, and happy new year :-) !

[Tomaz Lemos]

Thanks a lot Bertil, and happy new year to you too!