The conventional method of representing a branching for deriving values or executing certain logics is by using an
if-else statements to determine when to do what.
if-else statements can quickly build up to ladders and create code that is very hard to understand and maintain.
This blog is to share an approach that we came up with a systematic approach to avoid
Avoiding if-else ladders are not a new thought, for example, the book “Clean Code” talks about avoiding if else using polymorphism. But that solution is not practical in all the use cases, and we might end up in abusing polymorphism with that approach.
The approach that we came up with is also not a silver-bullet, but a practical data-driven approach which can be used when you can express your logic as tables.
Whatever the conditional logic that you have start by expressing the logic in tabular form.
Can be expressed as data-table like,
|Signal Color||Action to be taken|
|Yellow||Prepare to stop|
Now that we have defined our conditionals in tabular format, lets see how can we express it as code.
When you have a 2-column table, the simple way to encode the data would be a
For example, the above signal table can be expressed as map like this,
Which would be better than the equivalent counterpart with if-else ladder,
If your conditional table is not straightforward key-value mapping, you would still achieve the same result with the strategy of encoding
data table as
Map with the key as
Predicate, where the evaluation is about iterating through each key set and
returning/evaluating the value when the corresponding key is evaluated to true.
For the data table,
Map can be,
And the code to figure out the grade can be,
Note: If the order of the evaluation of the predicates matters, you can go ahead with LinkedHashMap.
Everything is fine until now when you have a 2-column table representation of your conditional logic. It would soon be problematic when you have multiple conditions to check for. In such cases, with
Map approach, you might have to create nested maps, which would create complexity and defeats the purpose of the effort that we’re working towards.
In such situations in which the
Map approach is not enough, see if you can encode your tabular representation into bit more sophisticated data (for ex, as JSON).
For example, The logic,
Can be expressed in tabular format as,
|Condition 1||Condition 2||Condition 3||Condition 4||Return Value|
|True||True||Don’t Care||Don’t Care||Value 1|
|False||True||Don’t Care||Don’t Care||Value 4|
|Don’t Care||False||False||Don’t Care||No conditions met|
And when you need to encode it in code, you can express it in JSON as,
And the equivalent code that evaluates can be,
Note: Instead of imperative way of evaluating the JSON, you can also leverage on libraries that supports JQ so that the code that evaluates can also be made declarative.
If you’re a situation where you find yourself in a position that you’re unable to express the conditionals in a consistent way within the JSON, you can see if you turn to small DSL utilities like j-s-exp.
A more comprehensive example for this could be found in our earlier blog post.
You can turn to formal rule-engine libraries that implements Decision Tables, which would be a straightforward mapping from data representation that you have done in step#1.
For example, libraries like Drools have features out-of-the-box that allows you to define and use Decision Tables from excel and use it.
Separation of concerns: The “What” (business logic expressed as Map/JSON) and “How” (code leveraging the data) part of the code is separated out. So that all your business logic is encoded in code without other logics, and there would be a one-to-one mapping between your data representation and business spec.
Flexibility: You can add, modify, or remove conditions without changing the code. This allows for easier customization and adaptation to evolving requirements.
Testability: Since the conditions and actions are externalized, you can create targeted test cases, ensuring comprehensive test coverage without the complexity of testing nested conditions.
Readability and Maintainable Code: Since the “What” and “How” parts are separated, when there is a change in business logic just change the data. When you want to optimize or bug fix, it would mostly be touching code that leverages the data representation.
Overall, this thought process helped us to write much cleaner and maintainable code. If you have similar thought process and stuck on simplifying your code, do talk to us. More than happy to discuss and help.