Summary

The web content advocates replacing complex logical statements with table-driven methods for improved software maintainability and flexibility.

Abstract

The article "Replacing Logical Statements With Table Driven Methods" suggests that traditional if-else statements become cumbersome as software complexity grows. It proposes using decision tables and a dictionary-based lookup approach to handle conditional logic, which simplifies the code and makes it easier to manage, especially when dealing with multiple languages or other varying requirements. The author illustrates this by transforming a typical month name retrieval scenario into a more scalable solution using a table-driven design. This method allows for easy updates and additions to the decision logic without altering the core functionality of the code.

Opinions

Logical statements, such as if-else, are deemed inefficient for complex or frequently changing requirements.
The table-driven design is presented as a superior alternative for managing decision logic, offering better scalability and maintainability.
The author emphasizes that adding more if-else statements to accommodate new conditions, like additional languages, leads to unmanageable code.
Refactoring to a table-driven approach is shown to significantly reduce the complexity of the code, making future enhancements straightforward.
The article suggests that using a dictionary as a lookup table in conjunction with a well-structured class can provide the flexibility needed to handle evolving software requirements elegantly.
The author, Nicklas Millard, positions himself as an experienced software engineer, advocating for practices that lead to cleaner, more maintainable code in the finance sector and beyond.

PRACTICAL PROGRAMMING ADVICE

Replacing Logical Statements With Table Driven Methods

Let’s build better software with decision tables in place of if-else

We can do better — much better — than implementing logical statements. We’ll transform the code on the left, into what you see on the right.

Before and after refactoring logical statements into table driven design.

But first, a proper introduction to the issue at hand.

You typically start writing your usual logical statements when checking a set or series of values to decide what code to execute.

It’s fine provided the requirement does not change and is of low complexity. At this point, logical statements aren’t an issue.

They make for fast and easy development. However, as soon as complexity rises, you’ll quickly find yourself searching for ways to refactor growing logical if-else statements into a more suitable approach.

Logical statements, like if-else, are clumsy.

You often need to replace the growing mess with table driven design.

Our current situation with logical statements

Say our product owner is giving us this table below. We need to implement a way of displaying the name of months based on an integer value.

It’s no real issue yet. You can easily turn this into a bunch of if-else statements — or a switch — and never look back. You’d perhaps implement it like this below.

So far, a perfect candidate for logical statements.

However, down the road, a new requirement is thrown at you. This time, you’ll need to accommodate for translations as well. The decision table is modified to allow for this.

As a business person, it’s no big deal, right? Slap in an extra column, a few extra rows in the spreadsheet and it’s all good. Task completed.

Many less experienced developers might attack this by just adding more else-if statements, checking an additional value, such aslanguage. You see, this approach quickly proves unsustainable.

Imagine when a bunch of additional languages is introduced. It’ll become a headache-inducing nightmare.

However, it doesn’t need to get this crazy.

As a developer, you can easily re-arrange your code to allow for almost the same flexibility as to just add an extra column and few rows.

“I’m intrigued. Show me how it’s done.”

There’s an incredibly simple solution.

We can condense all the logical branching inside GetMonthName() to this very simple line.

It’s done by using a dictionary as our lookup table. Our complete MonthOverview class now looks like this below.

Notice how we’ve completed pulled out the month names and all the nasty if-else’s. Now, we just expect whoever uses our class to provide it with configs through the constructor.

You’ll need to create the lookup table

It’s basically a two-step process now, that’ll allow for much greater flexibility.

Generate a lookup table or dictionary in this case.
Instantiate the object using the configurations needed

As you’ve probably already spotted, it’s now only a matter of providing an additional key-value pair to the langConfig, and we have an additional language added.

Resources for the curious
-------------------------
Code Complete 2nd edition by Steve McConnell

Your Controllers Are Doing Too Much — This Is How To Simplify Them

No business logic or data access allowed. Refactor to very thin controllers for better maintainability and flexibility

medium.com

Better Software Without If-Else

5 Ways to Replace If-Else. Beginner to advanced examples

medium.com

Stop Using If-Else Statements

Write clean, maintainable code without if-else.

medium.com

Nicklas Millard is a software development engineer in one of the fastest-growing banks, building mission-critical financial services infrastructure.

Previously, he was a Big4 Senior Tech Consultant developing software for commercial clients and government institutions.

New YouTube Channel (@Nicklas Millard)

Connect on LinkedIn