Eliminate Boolean Explosion by Enumerating States
There are several fundamental problems with trying to manage the state of a function through the use of booleans. The first is often referred to as "boolean explosion". For every boolean we add to a function, we increase the number of possible states at a rate of 2^n where n is the number of booleans. Running the math just a few times quickly reveals an absurd amount of states.
The second problem is that many of these states are "impossible states", states our application should never be in. The example in the lesson is that the light bulb should not be isLit and isBroken. It's simply not possible, and is an inaccurate modeling of an actual light bulb.
The way we solve for this problem is by enumerating the possible states. In other lessons in this course, we'll do that with state machines, but for now, we'll do that by enumerating the possible states and updating our function to only utilize these possible states.
Instructor: [00:00] Here I have a function that simulates the functionality of a light bulb. It tracks the state of the light bulb through the combination of two Booleans, isLit and isBroken. As this function is currently written, it is trivial to get into an impossible state. I will toggle the bulb from unlit to lit, call the break method, and we have a bulb that is both lit and broken.
[00:21] We can solve this problem imperatively by guarding against certain outcomes. We can add a guard and toggle that checks the isBroken state, guarantees isLit is set false, and returns early. We can also ensure that when the bulb is broken, we also update isLit to false. Now, running the same methods and logging them out produces a better result.
[00:45] There's a better way to solve this, though. To start, we're going to enumerate only the possible states of our light bulb. I'm going to create an enum using an object of only the possible states of the light bulb, lit, unlit, and broken. You could also use a map, if you prefer.
[01:02] Next, we'll refactor our function by removing the Booleans isLit and isBroken and replacing that with a single value called state. We will set the default state to unlit and update the state method to return this value instead.
[01:17] Next, we'll refactor our toggle method. Instead of toggling a Boolean, we'll instead attempt to toggle between lit and unlit states. We can do this with a switch statement. If we're in the lit state, we'll set the state to unlit and vice versa. If we're in neither of those states, we know that we're in the broken state, and we don't have to do anything.
[01:36] Lastly, we can update our break method to set the state to broken. We now have a light bulb function that has enumerated only the possible states, methods that can only set the state to one of those possible ones, and returns a single possible state with each event performed on the light bulb.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!