Forem: Tomaz Lemos

What Happens Between @SqsListener and Your Method in Spring Cloud AWS SQS

Tomaz Lemos — Mon, 20 Apr 2026 05:13:54 +0000

Originally published at tomazfernandes.dev.

You write a method, add @SqsListener, and messages start arriving. It is easy to see that as a simple annotation-to-method shortcut.

In practice, Spring Cloud AWS SQS assembles a listener container at startup based on that annotation, and at runtime the container holds an async pipeline between the queue and your code.

That pipeline controls how messages are polled, dispatched, processed, and acknowledged. It influences throughput, failure handling, and whether processing actually results in the message being removed from the queue.

Making it look simple is exactly what a framework is supposed to do. Understanding what happens underneath gives you leverage for the hard parts.

This post builds a practical model of that system by showing how @SqsListener annotations become configured containers, how the runtime pipeline shapes message outcomes, and which concrete components implement each stage.

Companion resources

Architectural overview: A deeper reference with diagrams in the Spring Cloud AWS repository.
Example project: Runnable scenarios for assembly, interception, error handling, and acknowledgement; also a playground for experimenting with the framework.

Table of contents

Two phases: assembly and runtime
Assembly: how listener behavior is built
Runtime: how the container pipeline shapes message outcomes
- Ingress: polling under backpressure
- Dispatch: delivery strategy
- Processing: handling the message
- Acknowledgement: turning processing into deletion
The async runtime model
Seeing it in action
Takeaways

Two phases: assembly and runtime

To start building this model, the first useful distinction is between assembly and runtime.

Suppose you write this listener method:

@SqsListener("orders-queue")
public void handle(OrderCreated event) { /* ... */ }

In the assembly phase, the framework turns that method into a configured container with the components that define its runtime behavior. In the runtime phase, messages begin to flow through that container’s asynchronous pipeline.

Assembly: how listener behavior is built

The assembly phase follows a common pattern in Spring messaging projects, with the work split across two parts of Spring startup.

During bean post-processing, SqsListenerAnnotationBeanPostProcessor detects @SqsListener annotations and turns each one into an Endpoint that describes the listener: queues, listener method, and configuration. These endpoints are then collected by the EndpointRegistrar.

At a high level, the first part of the assembly flow looks like this:

At this point, the listener has been described as an endpoint. The next step is to turn that endpoint into a container.

When afterSingletonsInstantiated() is invoked, the EndpointRegistrar processes the collected endpoints. For each endpoint, it resolves the MessageListenerContainerFactory to use, creates the corresponding container, and registers it in the MessageListenerContainerRegistry.

The second part of the assembly flow looks like this:

By the time startup completes, each @SqsListener method is represented by a message listener container with its own identity, queue bindings, and runtime configuration.

To customize the assembly phase, for example, setting a default factory or configuring endpoint registration, SqsListenerConfigurer is the main entry point. It provides access to the EndpointRegistrar before endpoints are processed into containers.

Runtime: how the container pipeline shapes message outcomes

If you have used other Spring messaging projects such as Spring for Apache Kafka, the assembly side of this model will feel familiar. The runtime phase is where Spring Cloud AWS SQS takes a different approach.

Typically, runtime behavior in these projects is centered in a single container class. In Spring Cloud AWS SQS, the container runs a composable asynchronous pipeline built around the AWS SDK’s SqsAsyncClient.

At runtime, the focus shifts to how messages enter the container, move through the processing pipeline, and eventually get deleted or made visible again.

That gives us a runtime model built around four responsibilities:

Ingress: balance polling and backpressure as messages enter the container
Dispatch: route polled messages into processing according to the delivery strategy
Processing: run the message through the processing pipeline
Acknowledgement: decide and execute message deletion based on processing outcomes

At this level, the runtime flow looks like this:

The MessageListenerContainer uses the ContainerComponentFactory to create the components used in these stages at startup.

Ingress: polling under backpressure

At the ingress boundary, throughput depends on the balance between polling and backpressure. This is one of the main controls over resource usage: if ingress is too permissive, the application can consume too much memory or compute resources; if it is too restrictive, messages can accumulate in the queue even though the application could safely handle more messages.

The ingress cycle looks like this at a high level:

In Spring Cloud AWS SQS, the MessageSource controls ingress into the pipeline and converts SQS messages into Spring Message instances. It keeps polling as long as the BackPressureHandler signals that more messages can be admitted in flight.

Polling behavior is configurable, including batch size and long polling settings that balance throughput and efficiency. As long as backpressure allows and the queue has enough messages available, multiple poll calls can stay in flight in parallel. When a queue is empty, the framework falls back to a single-poll model for that queue. As messages finish processing, room opens up and the container can keep polling.

By default, backpressure is mainly driven by internal in-flight capacity, but the mechanism is composable and can be extended with other signals such as downstream queue pressure or service availability.

Dispatch: delivery strategy

Once messages enter the container, the next question is how they should be delivered for processing. Delivery rules vary by queue and listener type: standard queues can fan out work in parallel; batch listeners may want one or more batches delivered as a single unit; FIFO queues need dispatch that preserves ordering while still allowing parallelism across message groups.

In Spring Cloud AWS SQS, MessageSink components are responsible for applying that strategy reliably. When the container starts, the ContainerComponentFactory selects and composes sink implementations based on queue semantics and configuration. For example:

A standard queue listener gets a FanOutMessageSink, which delivers each message to the processing pipeline in parallel. This is why a single @SqsListener can process multiple messages concurrently without any threading configuration.
A FIFO queue listener gets a MessageGroupingSinkAdapter composed with an OrderedMessageSink, which partitions messages by group and enforces sequential delivery within each group, preserving ordering while still allowing parallelism across groups.
A batch listener gets a BatchMessageSink, which delivers them as a single unit to the listener method.

Sinks and adapters share the same interface and can be composed without changing the upstream source or downstream processing pipeline.

Processing: handling the message

Message processing involves several connected concerns. A message may need to be enriched with headers, failures in listener logic may trigger fallback behavior, intermediate outcomes may need to be observed, and the result of these steps determines whether the message should be acknowledged or redelivered.

In Spring Cloud AWS SQS, the message processing stage is structured as an inner processing pipeline. Each stage in that pipeline is built around a user-provided component that can influence the next.

At a high level, the processing pipeline is structured like this:

Each stage can observe, transform, or react to the current processing state before passing control to the next:

MessageInterceptor (before): can enrich the message with headers or validate preconditions before the listener runs
MessageListener: invokes the method behind @SqsListener, where the actual business logic runs
ErrorHandler: catches listener exceptions and decides whether to swallow, transform, or propagate them, which directly affects whether the message gets acknowledged or redelivered
MessageInterceptor (after): sees the final outcome including any exception, making it a natural point for logging, metrics, or cleanup
AcknowledgementHandler: bridges the processing result into the acknowledgement stage, deciding whether the message should be deleted or left for redelivery

While the pipeline is built on an asynchronous foundation, the framework accepts combinations of synchronous and asynchronous variants of these components without extra configuration. Asynchronous variants enable an end-to-end non-blocking pipeline, while synchronous ones are adapted on the fly to a message-per-thread or batch-per-thread model.

Once the final stage of the processing pipeline completes, backpressure capacity is released. The message then either proceeds to acknowledgement or becomes visible again after the visibility timeout.

Acknowledgement: turning processing into deletion

As the message moves through the previous stages, it still sits in the queue, invisible until the visibility timeout expires. Acknowledgement is the stage that turns processing results into actual deletion. That mechanism has to balance several cross-cutting concerns at once: efficiency, throughput, ordering guarantees, observability, and extensibility.

Acknowledgement performance must keep up with polling and processing throughput. If it falls behind, completed messages can accumulate waiting for deletion. That increases the chance of visibility timeouts expiring before the delete call happens, which can lead to redelivery, duplicate work, and degraded performance.

In Spring Cloud AWS SQS, the acknowledgement flow is split across four main components:

The AcknowledgementHandler in the final stage of the processing pipeline decides whether a message should proceed to deletion or stay in the queue for redelivery. If it should be acknowledged, the AcknowledgementProcessor applies a strategy that varies by queue type:

For standard queues, acknowledgements are batched by default and executed in parallel based on configurable batch thresholds and scheduling.
For FIFO queues, acknowledgements respect message-group ordering: they can run in ordered parallel batches across groups, or synchronously after each message when out-of-order reprocessing must be avoided.

The AcknowledgementExecutor issues the actual delete calls, which can succeed fully, fail partially, or fail completely. The AcknowledgementResultCallback observes the outcome, enabling custom recovery strategies as well as instrumentation. When partial failures occur, SqsAcknowledgementException exposes which acknowledgements succeeded and which failed, so the callback can inspect and react to each case.

The async runtime model

At runtime, SQS interaction is mostly I/O-bound: polling is a network call, and acknowledgement eventually becomes a delete request back to SQS. In a synchronous design, threads would spend much of their time waiting on those operations.

Spring Cloud AWS SQS is built on SqsAsyncClient, where operations such as receiveMessage() and deleteMessageBatch() return CompletableFuture. That lets the container track in-flight work without tying progress to blocked threads. Internally, CompletableFuture composition gives the framework declarative control over parallelism and non-blocking orchestration throughout the pipeline.

The framework provides both synchronous and asynchronous variants of message processing components, and users can provide their own TaskExecutor for full control of what threads their code runs on. This threading model allows users to write regular blocking code without worrying about the underlying async complexity, and choose where and when to work with asynchronous code when it fits their use case.

Seeing it in action

The example project makes these stages concrete through a set of toggleable scenarios. It runs with Docker only, so you do not need a local Java setup.

make run-assembly: logs container metadata at startup
make run-interceptor: shows before/after interceptor hooks around each message
make run-error-handler: shows failure handling and SQS redelivery
make run-ack-callback: shows acknowledgement results after delete requests
make run-all: runs all scenarios together

Takeaways

Spring Cloud AWS SQS aims at making @SqsListener simple to use, while underneath it is transparently assembling a container that handles ingress, dispatch, processing, and acknowledgement at runtime. Each of these concerns is mapped to a dedicated set of components that can be swapped or extended to adapt to queue semantics and user requirements.

With that model in mind, each layer gives a clear starting point for understanding or changing behavior:

To customize how listeners are built and configured, the assembly phase and its components are the first candidates.
If throughput is not matching expectations, the relevant layer is usually ingress and backpressure.
To observe, enrich, or react to messages at different points, the processing pipeline and its extension points are the place to start.
If messages are not being deleted or getting redelivered unexpectedly, that naturally points to the acknowledgement flow.

For the full architectural reference, including the original diagrams and component map, see the architectural overview. For the user-facing module reference, including configuration and runtime options, see the Spring Cloud AWS SQS documentation.

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!