Flags or Objects — Deciding the victor

Most of us have heard of the terms data abstraction and encapsulation whenever a reference is made to Object Oriented Programming. Like most of the developers, I had nothing but praises about having interfaces and abstract classes in code base. And when I was almost sure that I was following all the OOP principles and best practices, I get to learn something which I otherwise couldn’t have even thought of:

Conditional processing using flags can be replaced with interface implementations

This made me wonder that I have been using flags with no issues as of now. It’s pretty simple to create an enum, use switch case and get the desired results. And it works well too. But usage of flag is considered an Anti Pattern. So the question here is:

Are flags really bad? Should we replace all flags (boolean/string/enums) in our code?

Before we jump on to find answers to this question, let’s first see how do we remove flags from our code. Take a really popular example of stopwatch with basic functions — start(), stop(), resume(), pause()

Here is a dummy implementation of stopwatch using a flag state which keeps changing its value whenever a stopwatch operation is invoked. But there is more to that. We also need to take care of current state and add safety checks before responding to any operation.
For instance, you can’t pause an already stopped watch, or you can’t resume a watch in running state.

At first look the above code looks pretty simple, and easy to understand. But if you look more closely, each method consists of some if and exception. This actually hides the main business logic and risk of missing out a corner case is high.

Now let’s try to solve the above two issues. The key rule to remove such state flags is:

• Create an interface with flag name having all the functions
• Create implementations for each of the flag value

First we create an interface with name StopWatchState having all the methods of stopwatch.

Now create an implementation for each of the possible state of stopwatch i.e. Running, Stopped and Paused.
Here is a sample implementation with just logging to console based on the current state (for the sake of understanding only). For instance, you can’t start or resume a stopwatch in running state.

Similarly let’s create implementations for stopped and paused state.

Now let’s implement StopWatch.java again using StopWatchState.

The beauty of this code or rather java is that we can assign any of the implementation to its interface object as it conforms to same protocol/rules. We can see that flag is now removed and so are the conditions on it. Every time a stopwatch operation is performed, the state object is updated accordingly specifying which operation was invoked. Hence, whenever we invoke any operation, we know it’s previous state.

What we just did by removing flags — an anti-pattern, using interface-implementations is called State Design Pattern

State design pattern is used when an Object changes its behavior based on its internal state.

Now since we have seen both the ways of implementing the stop watch, it’s time we go back to the original question:

Are flags really bad? Should we replace all flags (boolean/string/enums) in our code?

Pros of State Design pattern over Flags

• Easy to maintain and debug as we always know the current state and implementation of an operation in that state. There are no confusing if-else or switch cases.
• Easy to extend by just adding another implementation of the interface and minimal business logic change.
• Easy to separate business logic from implementation challenges.

Pros of Flags over State Design pattern

• Less code as a single flag needs to be maintained than classes. Also, the design pattern over complicate the code in scenarios of boolean flags where we simply need an if-else. This point can be argued over based on use case.
• Comparatively easy to visualize and implement rather than design pattern.

Having said all of this, in my personal opinion, state pattern is better over flags in scenarios where we need to deal with multiple states. And the opinion becomes stronger if the states can be extended further.
But if there is a simple use case which can be solved by a boolean flag, there is no harm using it if we are sure that we are not going to extend it in future.