Stop using the if-else statement


You have looked at countless tutorials using If-else statements. You probably also read programming books promoting the use of If-else as the actual branching method.

Perhaps this is even your default mode to use If-else. But let’s get this over with right now by replacing If-else with state objects.

Note that this approach can be used if you are writing a class with methods that need to change its implementations depending on the current state. You would take a different approach if you were not dealing with the changing state of the object.

Even if you have heard about the state template, you may wonder how it is implemented in ready-for-production code.

For those who are still in the dark, here is a very brief introduction.

You will increase complexity with any new conditional requirement implemented using If-else.

Using a state template, you simply change the behavior of objects using specialized state objects instead of If-else statements.

Gone are the days when the code looked something like the one shown below.


You, of course, wrote more complex branches before. A few years ago, I was sure of that.

The branching logic given above is not even very complicated – but try adding new conditions, and you will see that it becomes more complicated at times.

Also, if you think creating new classes instead of just using branching statements sounds annoying, wait until you see it in action. This method is concise and elegant.

Even better, it will make your code base more SOLID, with the exception of the letter “D”.

“Well, I believed that if-else is evil, now show me how to avoid messy branching code.”

We’ll look at how I replace If-else in production-ready code. This is a fictitious example, but the approach is the same as I used in the code bases for large clients.

Let’s create a very simple class Bookingwhich has several states. It will also have two public methods: Accept() and Cancel().

I drew a chart to the best of my ability, which displays the various conditions in which the reservation may be located.


Refactoring branching logic from our code is a three-step process:

  1. Create an abstract base state class
  2. Implement each state as a separate class inheriting from the base state
  3. Let the class Booking has a private or internal method that takes a base state class as a parameter

Demo time

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


Note that this class also has two methods, Accept and Cancel – although here they are marked as internal.
In addition, the base state has a “special” method EnterState(Booking booking). It is called whenever a reservation is assigned a new state.

Secondly, we create separate classes for each state that we want to represent.


Notice how each class represents the state described in the beautiful diagram above. In addition, CanceledState will not allow our reservation to go into a new state. This class is very similar in spirit to the null object pattern.

Finally, the booking class itself.


Let’s see, is the booking class just delegating authority to accept and reject?
This allows us to eliminate most of the conditional logic and allows each state to focus only on what is important to itself – the current state also has the ability to transfer the reservation to a new state.

How to deal with new conditions

If a new function was usually implemented using some conditional check, then now you can simply create a new state class.
It is very simple. You no longer have to deal with the bulky if-else statement.

How to save a state object in a database

The state object does not matter when saving the object, for example, in an SQL or NoSQL database. It is only important to know the state of the object and how it should be displayed in the column.
You can match the state with a readable name, enumeration, or integer. All that is convenient for you, as long as you have some way to convert the stored value back to a state object.

But you still use if

Yes, he is very important. Especially when used as test points. It is the If-else combination that is the main reason for the headaches of code support.

This is a bunch of extra classes

Really. As I mentioned in another article, complexity arises not from the number of classes that you have, but from the responsibilities that these classes take on.
Having a large number of specialized classes will make your code more readable, maintainable, and simply more enjoyable to work with.


Learn the details of how to get a sought-after profession from scratch or Level Up in skills and salary by completing SkillFactory paid online courses:

Read more

  • The coolest Data Scientist does not waste time on statistics
  • How to Become a Data Scientist Without Online Courses
  • Sorting cheat sheet for Data Science
  • Data Science for the Humanities: What is Data
  • Steroid Data Scenario: Introducing Decision Intelligence

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *