Image for post
Image for post

APPLIED DESIGN PATTERNS: STATE

Stop Using If-Else Statements

Write clean, maintainable code without if-else.

Nicklas Millard
Jun 16 · 5 min read

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.

Gone are the days with code looking like this below.

Poor if-else statements
Poor if-else statements
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.

Image for post
Image for post

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

  1. Create an abstract base state class
  2. Implement each state as a separate class inheriting from base state
  3. 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.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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.

The Startup

Medium's largest active publication, followed by +718K people. Follow to join our community.

Nicklas Millard

Written by

Tech writer with 560K+ views. Sharing my opinion and what I learn. Danish C# backend engineer in FinTech. Ex Big4 senior tech consultant.

The Startup

Medium's largest active publication, followed by +718K people. Follow to join our community.

Nicklas Millard

Written by

Tech writer with 560K+ views. Sharing my opinion and what I learn. Danish C# backend engineer in FinTech. Ex Big4 senior tech consultant.

The Startup

Medium's largest active publication, followed by +718K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store