[MUSIC] Think about what your doing this very second. Your obviously watching this lesson, but what else are you doing? Are you sitting, standing, laying down? Let's say I asked you to do a dance but remain in the same state. If you are sitting down, your dance might involve you waving your arms and shoulders and bobbing your head. If you are standing, you would be able to add some foot work to your dance. If you are laying down, you might throw your hands in the air and wiggle your body. All I had to do was tell you to dance, and you chose a dance that was applicable to your current state. I didn't have to specify what your dance should look like. If I told you to tap dance, which is a dance that requires you to tap your feet on the ground, that would be difficult if you we're on the lying down state. Likely, you would have to change your state in order to complete that action. Since the objects in your code are aware of their current state, you can use this premise in your code. They can choose an appropriate behavior based on their current state. When their current state changes, this behavior can be altered. This is the state pattern. So, when should you use the state pattern? The state pattern is primarily used when you need to change the behavior of an object based upon the state that it's in at run-time. Let's look at an example. A vending machine represents state pattern well since it has several states and specific actions based on those states. Let's say I wanted to purchase a chocolate bar from a vending machine. The chocolate bar costs $1. I walk up to the vending machine, insert my dollar and make my selection. The machine then dispenses the chocolate bar. I take the chocolate bar and go on my merry way. This will be the typical case for this scenario, but let's explore some other situations that could happen. What if I walked up to the vending machine, inserted my dollar and then decided I didn't want the chocolate bar anymore? I would press the eject money button and the machine would return my dollar. What if the vending machine runs out of chocolate bars? The vending machine needs to be keeping track of it's inventory and notifying the customers when there is no more of a particular product left. If I represent this as a UML state diagram, it would look like this. From this diagram, you can see that there are three states: idle, has 1$, and out of stock. The vending machine is in one of these states at a time. You can also see that there are three triggers, or events. These triggers would be insert dollar, when the dollar is inserted, eject money, when there is a request to eject money, and dispense, when there is a request to dispense a product. There are two actions that the vending machine can do. These actions are doReturnMoney, or doReleaseProduct. Let's see what this might look like in code. My vending machine class would look like this. Take a second and think about the different states that the vending machine could be in. Before I approach the vending machine the machine is in an idle state, nothing is happening. What happens when I insert my dollar? The state of the vending machine changes. There are events to respond to and actions to perform that are now relevant to the vending machine. These would be responding to an eject money request by returning my money, and responding to a dispense request by releasing a product. A third state the machine could be in, would be if the machine is out of stock. It would no longer be able to dispense a product, so how to respond has changed. Let's take a look at one way that we can represent this in Java. First, we'll make some singleton state objects. We define our three states as new State objects. State.Idle would denote the idle state, state.HasOneDollar would denote the machine having one dollar, and state.OutOfStock would denote that this machine is out of stock. Our VendingMachine class would look like this in part, currentState refers to a specific state object, whichever denotes the current state of the vending machine. When the machine is instantiated with a stock count greater than zero, the current state is set to State.Idle. If the stock count is not greater than zero, the current state is set to State.OutOfStock. Now, if we look at what happens when I insert a dollar, you can see that if the current state of the vending machine was State.Idle then the current state changes to State.HasOneDollar. If the currentState of the machine was already State.HasOneDollar, my money is returned and the currentState is set to State.Idle. If the currentState of the machine was already State.OutOfStock, my money is returned and the currentState stays in State.OutOfStock. But these state objects seem pretty massive and don't have much responsibility themselves. Let's now look at how you can restructure this properly using the state design pattern. We will define a state interface with a method for each trigger that a state needs to respond to. That is insertDollar, ejectMoney and dispense. And we'll have state classes that implement the state interface. One for each state needed, that is IdleState, HasOneDollarState and OutOfStockState. This is the state interface. State classes must implement the methods in this interface to respond to each trigger. Next our IdleState class would look like this. Our IdleState class now implements the State interface. When a dollar is inserted the insertDollar method is called, which then calls a set state method upon the vendingMachine object. This changes the current state of the machine to the HasOneDollarState. Similarly, in the HasOneDollarState class, when the eject money method is called, the money is returned and setState is called on the vending machine to change the state to the idle state. Here's what happens if the dispense method is called in the HasOneDollarState class. The product is released. Depending on whether stock remains after releasing the product, the vendingmachine's current state is set to either the idleState or the outOfStockState. The vendingmachine class constructor will instantiate each of the state classes. And the current state will refer to one of these state objects. The vendingmachine class would also have methods to handle the triggers as before, but now delegates handling to the current state object. Notice now, how much cleaner the code is, without having long conditionals in these methods. The structure of the state pattern generally looks like this. In our example,the vending machine is the context class. It keeps track of it's current state. When a trigger occurs and a request is asked of a context object, it delegates to a state object to actually handle the request. The state pattern is useful when you need to change the behavior of an object based upon changes to its internal state. You can also use the pattern to simplify methods with long conditionals that depend on the object state.
