Why another design pattern? 😠

It is a widely common task in Software to perform tests on an object and obtain the result of this process.

In Other Words ⚙️

Let’s imagine a pipeline of checks that an entity has to pass before being persisted to a database.
On every step, we want to return the reason for the check failure, if it does. Otherwise, we want to proceed to the next check.

A Real Life Example

Let’s write a function to verify that a given password 🗝 meets certain criteria.
Length should be between 8 and 14 characters.
Should have at least one upper case character and one lower case character.
Should have at least 2 digits.
Should have at least one special character.

Typical Solution 🟡

Let’s do it using Java code

What was wrong with it? 🚩

The implementation above has many flaws, however, the most important two are:
Breaks the single responsibility principle, as this function does more than one check (six ones to be exact).
The function checkPasswordAndSubmit is about 20 lines long, which can be shorter if implemented correctly.

H3he checkAndDo pattern way 🟢

We add a chain of check functions, each one tests a single aspect.
Note the naming convention of the functions check_*And_ where:

• * is the current check we are performing.
• ** is the final action we want to be done. For example checkPassWordLengthAndSubmit checkPassWordCaseSensitivityAndSubmit checkThatTwoDigitsAreGivenAndSubmit checkThatSpecialCharactersAreGivenAndSubmit

So, should you use this pattern? ❔❓

if you have a lot of tests to run over an object, and if you want to run a specific action for each test’s result, then this pattern will provide you with a clear, plug-like design to ensure that you won’t get lost while trying to understand what goes where.

Code on GitHub🖊