78: Design Patterns: State.

What is the state design pattern? The state behavioral pattern allows you to simplify your code when you have different modes of operation. Instead of writing all the code to perform the action in each mode, you instead define an interface with all the actions and have your class call through an instance of the interface. This is really just a specific application of polymorphism. You then declare separate concrete classes that implement the actions in their own way or in their own mode. With these concrete classes, you just need to select one and update the class that wanted to perform the action in the first place to refer to one of the concrete implementations. The episode describes a command class that implements the ability to move a hero in an adventure game forward. When the hero could only walk, maybe it makes sense for the command to directly implement the code needed to move the hero forward. But when another mode of transport is introduced such as riding a horse, the command class would have to choose between the two different ways of moving forward. This pattern describes how to have the command class call a virtual moveForward method instead. This method will resolve to either walking or riding. The nice thing about this pattern is that it makes it easy to add more modes. We could add swimming or rowing a boat as additional modes of transport for the hero. In each of these cases, the command to move forward doesn’t have to change or be extended anymore. It just calls the move forward virtual method of the state object. If you’d like to read the book that describes this pattern along with diagrams and sample code, then you can find Design Patterns at the Resources page. You can find all my favorite books and resources at this page to help you create better software designs. Listen for more about this pattern or read the full transcript below. Transcript The basic description says that this pattern allows objects to alter their behavior when internal state changes and this causes them to appear to change classes. Many applications and games have different modes where it seems like everything changes. A drawing program will have a set of tools that change the meaning of clicking and dragging with the mouse. One tool might select and then move images while another tool might outline and then resize images. Some games might allow the hero to move around and interact with the world differently when on foot vs. when riding a horse. These are the types of modes this design pattern helps you to simplify. To see how, let’s first think about what your code might look like without this pattern. Now this is going to be a short episode because this pattern is so heavily focused on the structure of the code. I can’t effectively read code on the podcast and have any chance that you’d understand. This is the biggest reason I stay away from reading actual code. That’s what the live classes are for. But I’ll do my best to describe in general terms how this pattern can help you write better code. Imagine you’ve already implemented the command design pattern from episode 72 and you’re about to execute a move forward command. Walking and riding a horse are very different activities but both can support the idea of moving forward. Without this state pattern your code might have an if statement that says “if walking” then move forward like this block of code describes, “else” then move forward like this other block of code describes. The total length of the code in the command source file will be longer because it has to accommodate different ways of moving forward. This pattern will be repeated for every other command too. What happens when you need to add support for swimming? Now you need to go through all the commands and not only add the extra code but change the structure of your if statements. Maybe you decide to toss the if statements and go with switc