Stop Using If-Else Statements
By: Nicklas Millard
Tags: Technology, Software Engineering, Csharp, Programming, Software Development

APPLIED DESIGN PATTERNS: STATE

Stop Using If-Else Statements

Write clean, maintainable code without if-else.

You’ve watched countless tutorials using If-Else statements. You’ve probably also read programming books promoting the use of If-Else as the de facto branching technique.

It’s perhaps even your default mode to use If-Else. But, let’s put an end to that right now, by replacing If-Else with the state objects.

Note that you’d use this approach if you’re writing a class with methods that need its implementations to be changed depending on the current state. You’d apply another approach if you’re not dealing with an object’s changing state.

Even if you’ve heard about the state pattern, you might wonder how it is implemented in production-ready code.

For anyone who’s still in the dark, here’s a very brief introduction.

You’ll increase complexity with any new conditional requirement implemented using If-Else. Applying the state pattern, you simply alter an objects behavior using specialized state objects instead of If-Else statements.

Gone are the days with code looking like this below.

Warning: PTSD trigger — also, hope you caught the logical error in here (other than the whole thing being a mess)

You’ve certainly written more complicated branching before. I have for sure some years ago.

The branching logic above isn’t even very complex — but try adding new conditions and you’ll see the thing explode.

Also, if you think creating new classes instead of simply using branching statements sounds annoying, wait till you see it in action. It’s concise and elegant.

Even better, it’ll make your codebase more SOLID, except for the “D” part tho.

“Okay, I’m convinced If-Else is evil, now show me how to avoid messy branching code”

We’ll be looking at how I replace If-Else branching in production-ready code. It’s a made-up example, but the approach is the same I’ve used in codebases for large clients.

Let’s create a very simple Booking class, that has a few states. It’ll also have two public methods: Accept() and Cancel() .

I’ve drawn a diagram to the best of my abilities that displays the different states a booking may be in.

Refactoring branching logic out of our code is a three step process:

Create an abstract base state class Implement each state as a separate class inheriting from base state Let the Booking ` class have a private or internal method that takes the state base class as a parameter

Demo time

First, we need a base state class that all states will inherit from.

Notice how this base class also has the two methods, Accept and Cancel — although here they are marked as internal.

Additionally, the base state has a “special” EnterState(Booking booking) method. This is called whenever a new state is assigned to the booking object.

Secondly, we’re making separate classes for each state we want to represent.

Notice how each class represents a state as described in the beautiful diagram above. Also, the CancelledState won’t allow our booking to transition to a new state. This class is very similar in spirit to the Null Object Pattern.

Finally, the booking class itself.

See how the booking class is simply delegating the implementation of Accept and Cancel to its state object?

Doing this allows us to remove much of the conditional logic, and lets each state only focus on what’s important to itself — the current state also has the opportunity to transition the booking to a new state.

How to deal with new conditional features?

If the new feature would normally have been implemented using some conditional checking, you can now just create a new state class.

It’s as simple as that. You’ll no longer have to deal with unwieldy if-else statements.

How do I persist the state object in a database?

You don’t.

The state object is not important when saving an object to e.g. an SQL or NoSQL database. Only knowing the object’s state and how it should be mapped to a column is important.

You can map a state to a friendly type name, an enum or an integer. Whatever you’re comfortable with, as long as you have some way of converting the saved value back into a state object.

But you’re still using IFs?

Yes — they’re essential. Especially when used as guard clauses. It’s the If-Else combination that is a root cause for maintainability headaches.

It’s a lot of additional classes!

Indeed. As I’ve mentioned in another article, complexity does not originate from the number of classes you have, but from the responsibilities those classes take.

Having many, specialized classes will make your codebase more readable, maintainable, and simply overall more enjoyable to work with.