DEV Community: Tomaz Lemos

An IoC pattern to avoid repetitive if statements

Tomaz Lemos — Tue, 31 Dec 2019 05:30:10 +0000

In my previous post I shared two patterns that helped avoiding repetitive if statements, and we had a great discussion about imperative, if-based styles and declarative ones.

In this post I want to share another pattern which I think is great to expand our programming toolset.

I'll address some of the tradeoffs I see in it against the more traditional if-based approach, and I'd really like you to tag along and share what pros and cons you see in them in the comments. Let's do this together?

The examples are in Java but it should translate well to any other OO language.

If you prefer, skip right to the code

The pattern

This pattern is based on Java's Spring framework, and it's main point is that it offloads from the main class to the instances themselves the responsibility of knowing whether or not it is capable of, or should, handle a specific input, thus inverting the flow control.

It's widely used by Spring to find out which converter or mapper to use for a given input. Part of its value derives from being able to use unknown custom implementations of the interfaces provided by the user, but I do find value in using it for known types as well.

The context

For context, let's say we have an application that has to handle lots of different kinds of data, based on a what's the data's url’s country passed as a path parameter. Something like https://dev.to/myapp/data?url=http://www.google.com.br (I didn't escape the path param's url to make it clearer).

The application's job would be to retrieve the IncomingData from the url, and then pass it to the proper DataHandler provided by the Selector.

We might have a DataHandler interface that would be implemented by many classes, such as BrazilianDataHandler, SpanishDataHandler, FrenchDataHandler, etc, and a Selector to provide the correct instances.

Looking at the code should make it more clear, so let's do just that.

The usual if-based approach

Let’s start with an interface such as:

public interface DataHandler {
    ProcessedData handleData(IncomingData data);
}

A concrete implementation of the interface might look like:

// Other countries' handlers could be implemented the same way
public class BrazilianDataHandler implements DataHandler {
    @Override
    public ProcessedData handleData(IncomingData data) {
        // do stuff;
    }
}

Now let’s add the if-based selector:

public class DataHandlerSelector {

    private final DataHandler brazilianDataHandler;
    private final DataHandler argentinianDataHandler;
    private final DataHandler australianDataHandler;
    private final DataHandler frenchDataHandler;
    // Lots of other countries...

    public DataHandlerSelector(BrazilianDataHandler brazilianDataHandler,
                                        ArgentinianDataHandler argentinianDataHandler,
                                        AustralianDataHandler australianDataHandler,
                                        FrenchDataHandler frenchDataHandler) {

        this.brazilianDataHandler = brazilianDataHandler;
        this.argentinianDataHandler = argentinianDataHandler;
        this.australianDataHandler = australianDataHandler;
        this.frenchDataHandler = frenchDataHandler;
    }

    public DataHandler obtainDataHandlerFor(String url) {
        Assert.notNull(url, () -> "Url is null!");

        DataHandler dataHandlerToReturn;

        if (url.contains(".br")) {
            dataHandlerToReturn = brazilianDataHandler;
        } else if (url.contains(".ar")) {
            dataHandlerToReturn = argentinianDataHandler;
        } else if (url.contains(".au")) {
            dataHandlerToReturn = australianDataHandler;
        } else if (url.contains(".fr")) {
            dataHandlerToReturn = frenchDataHandler;
        // Lots of other countries...
        } else {
            throw new IllegalArgumentException("Url not supported: " + url);
        }

        return dataHandlerToReturn;
    }

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

And then a factory to instantiate the selector and it’s dependencies:

public class DataHandlerSelectorFactory {

   public static DataHandlerSelector createSelector() {
       return new DataHandlerSelector(new BrazilianDataHandler(), new ArgentinianDataHandler(), new AustralianDataHandler(), new FrenchDataHandler());
   }
}

Simple, right? This pattern has the great benefit of having a straightforward logic, which often leads to easier reasoning as it's a very common pattern.

There are some drawbacks I see, tough:

The Selector logic has to be modified every time we need to include another country
Lots of language specific words and symbols obscuring the business logic, which would be the condition - handler correlation
It tends to get huge over time, with lots of copying and pasting, possibly leading to bugs and poorer comprehensibility and maintainability
It is a single point of failure, meaning if some logic gets messed up you can mess several or all countries at once (think if you accidentally delete an "else if" line and the line above it...)
You may need to see both the Selector and the implementation class to get the big picture about what the implementation class does

What do you think, do you agree with these points?

The IoC Selector pattern

In this Selector pattern the interface gets a new shouldHandle method:

public interface DataHandler {
    ProcessedData handleData(IncomingData data);
    boolean shouldHandle(String url);
}

And the Selector becomes:

public class DataHandlerSelector {

    private final List<DataHandler> dataHandlerList;

    public DataHandlerSelector(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: " + url));

    // You can 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());
        }
    }
}

Let's take a look at a sample implementation of the new interface:

public class BrazilianDataHandler implements DataHandler {
    @Override
    public ProcessedData handleData(IncomingData data) {
        // do stuff;
    }

    @Override
    public boolean shouldHandle(String url) {
        return url.contains(".br");
    }
}

In this example we have changed the centralized approach of the first Selector into a decentralized approach, handing down to the implementations the responsibility of knowing whether or not it should act on a given input.

Overall, I like designs that forces us to make our intentions clear and makes it easy to figure out which are the business rules and exceptional cases.

I think this approach brings as advantages:

No modification needed in the Selector class when adding a new implementation
The condition and the logic itself are together, allowing for better clarity and cohesion
No cluttered language specific words clouding business rules
No copying and pasting
No single point of failure

And as drawbacks:

We loose sight of the greater picture of conditions
May take longer to reason about the first time you see it
One condition may interfere with the other if it is greedy and comes before the other

What about you, can you see any other advantages or drawbacks?

The wicked new requirement

Ok, now a new requirement has arrived, and there are some classes that will have to be verified first.

In this case we will have the .gov and .org urls that have to be addressed by special handlers regardless of their countries (I know that doesn't make that much sense but just bear with me 😄).

The if-based Selector's implementation might be something like:

public class DataHandlerSelector {

    // Constructor, properties and Assert class omitted for brevity

    public DataHandler obtainDataHandlerFor(String url) {
        Assert.notNull(url, () -> "Url is null!");

        DataHandler dataHandlerToReturn;

        // .gov and .org must come first
        if (url.contains(".gov")) {
            dataHandlerToReturn = governmentDataHandler;
        } else if (url.contains(".org")) {
            dataHandlerToReturn = organizationDataHandler
        } else if (url.contains(".br")) {
            dataHandlerToReturn = brazilianDataHandler;
        } else if (url.contains(".ar")) {
            dataHandlerToReturn = argentinianDataHandler;
        } else if (url.contains(".au")) {
            dataHandlerToReturn = australianDataHandler;
        } else if (url.contains(".fr")) {
            dataHandlerToReturn = frenchDataHandler;
        // Lots of other countries...
        } else {
            throw new IllegalArgumentException("Url not supported!");
        }

        return dataHandlerToReturn;
    }
}

Easy to implement right? But the way I see it, in this case the new added business rule is enforced only by that comment, which may or may not stand the test of time. We might be able to extract a method to put the first two ones in a different place but I do begin to smell spaghetti... We can discuss better solutions for this pattern in the comments if you have any.

And what about with the IoC Selector pattern?

Well, we might just create two lists:


public class DataHandlerSelector {

   private final List<DataHandler> firstHandlersList;
   private final List<DataHandler> secondHandlersList;

   public DataHandlerSelector(GovernmentDataHandler governmentDataHandler,
                              OrganizationDataHandler organisationDataHandler,
                              BrazilianDataHandler brazilianDataHandler,
                              ArgentinianDataHandler argentinianDataHandler,
                              AustralianDataHandler australianDataHandler,
                              FrenchDataHandler frenchDataHandler) {

        firstHandlersList = List.of(governmentDataHandler,
                                  organisationDataHandler);

        secondHandlersList = List.of(brazilianDataHandler,
                                  argentinianDataHandler,
                                  australianDataHandler,
                                  frenchDataHandler);


    public DataHandler obtainDataHandlerFor(String url) {
        Assert.notNull(url, () -> "Url is null!");
        return firstHandlersList
                .stream()
                .filter(handler -> handler.shouldHandle(url))
                .findFirst()
                .orElseGet(() -> getFromSecondHandlerList(url));
    }

    private DataHandler getFromSecondHandlerList(String url) {
        return secondHandlersList
                           .stream()
                           .filter(handler -> handler.shouldHandle(url))
                           .findFirst()
                           .orElseThrow(() -> new IllegalArgumentException("Url not supported!"));
    }

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

It sure is easier to code the first pattern, but in which do you think the new business rule is more clear? In my option, dealing with well reasoned patterns and interfaces usually leads to more reflection than action, and thus probably to better, more maintainable code, and with a clearer set of business rules and responsibilities.

But, of course, every pattern has its day of glory when applied in the proper situation, right?

So, what do you think are the pros and cons of each pattern? What points I made do you agree or disagree with? Is there another requirement change we should compare the two patterns against?

Let's address this in the comments!

Thanks a lot to @wrldwzrd89, @khtony, @bertilmuth and @t_dardzhonov for the early feedback on this post!

Keeping your code clean by sweeping out "if" statements

Tomaz Lemos — Fri, 27 Dec 2019 22:11:14 +0000

One of the most common things I see around that I think makes code more difficult to read is the overuse of "if" statements. It’s one of the first programming tools we learn, and it is usually when we learn that the computer can do pretty much anything we like, “if” we use those statements right. Following usually are long ours of printfs and debugging and trying to figure out why the program isn’t getting into that third nested "if" as we're sure it would do! That’s how many of us have approached programming, and that’s what many of us have grown used to.

As I studied more about code design and best practices I began noticing how using lots of if statements could be an anti-pattern, making the code worse to read, debug and maintain. And so out I went to find alternative patterns to those if statements, and I think the patterns I've found have improved my code’s readability and maintainability.

Of course there’s no silver bullet and any pattern should be used where it makes sense. I think it’s important for us developers to have options when attempting to write good quality code.

To illustrate this point I’ll share two simple examples, and I hope to hear your thoughts on the matter in the comments.

First let's see the example where we have to handle an incoming message from outside our application boundaries, and the object contains a string property specifying a type. It might be an error type from a mass email marketing, and we would have to translate that to our own domain’s error type.

Usually I see that implemented like this:



    private ErrorType translateErrorType(String errorString) {
        if ("Undetermined".equals(errorString)) {
            return UNKNOWN_ERROR;
        } else if ("NoEmail".equals(errorString)) {
            return INVALID_RECIPIENT;
        } else if ("MessageTooLarge".equals(errorString)) {
            return INVALID_CONTENT;
        } else if ("ContentRejected".equals(errorString)) {
            return INVALID_CONTENT;
        } else if ("AttachmentRejected".equals(errorString)) {
            return INVALID_CONTENT;
//      } else if (...)

        } else {
            throw new IllegalArgumentException("Error type not supported: " + errorTypeString);
        }
    }

You see where this is going, right? It could be a switch statement, and it would be just as cluttered, with much more language specific words than actual business domain language.

There are a number of approaches to getting rid of this kind of “if” entanglement, but I guess the simplest one is the use of a map.



    public class ErrorTypeTranslator {

        private final static Map<String, ErrorType> errorTypeMap;

        static {
            errorTypeMap = Map.of(
            "Undetermined", UNKNOWN_ERROR,
            "NoEmail", INVALID_RECIPIENT,
            "MessageTooLarge", INVALID_CONTENT,
            "ContentRejected", INVALID_CONTENT,
            "AttachmentRejected", INVALID_CONTENT
//          (…)
            );
        }

        public ErrorType translateErrorType(String errorTypeString) {
            return requireNonNull(errorTypeMap.get(errorTypeString),
                    () -> "Error type not supported: " + errorTypeString 
        }
    }

See the difference? Now the business logic is front and center, and any developer approaching this class should be able to very easily understand what it does and change it should it be needed. Lots of language specific words and symbols have disappeared making way for a much nicer, cleaner and less error prone code.

This kind of pattern is also very good for simple factories, where you can have a map of singletons, or even suppliers as values. For example, let’s say you have to return a handler bean based on an enum retrieved from the database.

What I usually see is something like:



    public class IntegrationHandlerFactory {

        private final EmailIntegrationHandler emailHandler;
        private final SMSIntegrationHandler smsHandler;
        private final PushIntegrationHandler pushHandler;

        public IntegrationHandlerFactory(EmailIntegrationHandler emailHandler,
                              SMSIntegrationHandler smsHandler,
                              PushIntegrationHandler pushHandler) {
            this.emailHandler = emailHandler;
            this.smsHandler = smsHandler;
            this.pushHandler = pushHandler;
        }

        public IntegrationHandler getHandlerFor(Integration integration) {
            if (EMAIL.equals(integration)) {
                return emailHandler;
            } else if (SMS.equals(integration)) {
                return smsHandler
            } else if (PUSH.equals(integration)) {
                return pushHandler
            } else {
                throw new IllegalArgumentException("No handler found for integration: " + integration);
            }

        }
    }

Let´s try using a Map instead:



    public class IntegrationHandlerFactory {

        private final Map<Integration, IntegrationHandler> handlerMap;

        public IntegrationHandlerFactory(EmailIntegrationHandler emailHandler,
                              SMSIntegrationHandler smsHandler,
                              PushIntegrationHandler pushHandler) {

            handlerMap = Map.of(
                        EMAIL, emailHandler,
                        SMS, smsHandler,
                        PUSH, pushHandler
            );
        }

        public IntegrationHandler getHandlerFor(Integration integration) {
            return requireNonNull(handlerMap.get(integration),
                            () -> "No handler found for integration: " + integration);
        }

    }

Much neater, isn’t it? Once again a very simple design that gets rid of many if / else if statements and makes it very easy to add new options.

There are many other patterns such as this, and I might do a post about those soon.

So, what do you think about this kind of patterns? Have you ever used a pattern like this? Are you more comfortable dealing with "if" statements?

Please let me know in the comments, I'd love to hear your feedback!

I made a post about another pattern that helps avoiding repetitive ifs, want to check it out?

Approaching software design principles

Tomaz Lemos — Mon, 15 Oct 2018 20:18:36 +0000

The other day a dear colleague asked me where I got my software modelling ideas from, and that led me to think about how I worked on system design principles. I learned a lot about my own process, and would like to share with you.

You see, I've always had an "always be learning" approach to software development, and the way I usually do it is that I try to impose myself some constraints in order to exercise some principle, and to force myself to learn thinking in different ways.

Otherwise I would always be tempted to go the way I’m more used to, and I think it would really slow down my learning curve.

I will share some examples of how that works for me, I’m pretty sure I didn’t invent it, but I hope you might find it useful.

The "composition over inheritance" case

One example is the "favor composition over inheritance" principle. I was pretty happy with my abstract classes and inherited methods, so why would that be attractive? I wanted to find out, so I put in place a constraint not to use any kind of inheritance anymore, even in cases where I thought it could make sense.

After some very awkward times where I had to think a lot to model requisites with composition that I could easily model with inheritance, the result was pretty awesome: I learned a very different way of structuring my code and saw clearly all the benefits of favouring composition over inheritance.

Today I’m a lot faster at designing with that principle in mind, and actually I haven’t felt the need for inheritance in a while.

The “immutability” principle

The same was true for immutable objects. After reading about it and playing with it for a while, I decided to focus on it, and since then all my objects “have” to be immutable.

Since I got used to this principle, immutability comes very naturally to me, and I the benefits are so great I just don’t use setters at all anymore (except in DTOs for parsing libraries compatibility).

The code is far easier to debug and to implement new features, as I don’t have to keep in mind the code parts in which a object’s state changes... It just doesn’t!

The point being that it started as a constraint, and evolved into a new way for me of thinking and designing software.

The "let's wrap it up and keep it short" momentum

This approach has helped me a lot in my journey as a developer, and has made work never boring.

What about you, how do you keep learning software development principles? Have you ever used such a constraints-based approach? Let us know in the comments!