Design Patterns - Observer

LUCIANO DE CASTRO MARTINS — Wed, 09 Apr 2025 17:33:16 +0000

Use cases

Imagine a scenario where you have a platform where users can create posts (like this one), and you received a new requirement so when a post is liked or disliked depending on how many likes it reiceived the post has to be monetized. The inicial solution is go where the post is liked/disliked and place an if like this:
if(post.likeCount > X){ callMonetization(post);}

Simple, now imagine that another requirement comes to you, saying that when any post is liked or disliked it should have an addtional log for compliance. So there you go place another if or inject another dependency on client code just to log the interesting part, this way you can end up with multiple if statement anytime you need to handle a new requirement, or having your code with multiple responsabilities/dependencies for each new requirement you have. Both scenarios are not good and observer design pattern can help us handle that.

Just for note the pattern is also known by other names like 'pub/sub'.

So let's create some code that implements the observer pattern.
This pattern uses an interface(observer) with methods that will be called on the observers (concrete implementation). First let's look at the arquitecture for a solution where we implemented a log requirement, a database save requirement, a notification requirement and a message queeu requirement(to focus on the pattern the specifics of those implementations were abstracted).

On that arquitecture we have a post entity, that have an author(person), an id, etc..
the observer interface and some pseudo concrete implementation, the post manager that will act as a proxy to our post like or dislike events calling the concret observers, the usecases that call manager's appropriate methods when invoked in client code, and offcourse there is the client code.

That said lets implement it in java:

the post entity

the observer interface

the post manager

the observer's implementation

and finally our client code:

so in client code we have a post manager used to add the observers (addObserver method), 2 usecases (like and dislike), people (one that create a post, and others that interact with it) and a method to create a fake id.

Executing the main method we'll see the following print statements (simplicity):

so that's it, whenever you want to react over some entity event like a post like/dislike, customer's transactions like withdraw, reimbursement, deposit, ect all you need to do is create another implementation of the observer interface, add it to the observers list in the manager and wait so your new observer will get called whenever an event occurs and you can use that call to handle your requirements.

Much better than inject not related code anywhere, don't you agreee?

Design Patterns - Pipeline

LUCIANO DE CASTRO MARTINS — Mon, 07 Apr 2025 16:49:12 +0000

Pipeline design pattern comes in handy when we need to execute sequences of steps over an input (request), were each step must be handled by differente software logic.

For instance, imagine a sequence of steps needed to approve a credit, a sequence of tests scores checking before decide if an student go up a year, medical exams results, etc...

Let's dive into a simple credit approval imaginary flow using typescript. You can define your own logic but for the sake of simplicity i'll keep it simple.

For this we'll need the following domain:
a card issuer represented by the enum CardIssuer, a person (Person Interface) and a Credit domain class (credit interface), see bellow:

So with the basic model created let's define our Pipeline implementation, but before that i'll need a CreditCardEvaluation class simply to wrap our domain so handling all related information becomes easier.

Finally an interface that defines our handlers contract (the contract to handle a request), and the pipeline class.

Now we must define what we want to validate/check. For that i defined a basic credit validator (BasicCreditProcessor), a guarantee validator and a credit card message processor, classes are as follow:

Now that we have our structure, let's test it:

and the result is:

a second test:

with the result:

by using the pipeline design pattern we avoid having a single class with multiple responsabilities and adding more processors "step/executors" are as easy as writing them and placing them inside the pipeline. that is it.

DEV Community: LUCIANO DE CASTRO MARTINS

Design Patterns - Observer

Use cases

Design Patterns - Pipeline