Hello, dear friends. In this video, we will examine the state design pattern. Let's begin. Imagine we have a package which is sent to a post office. The package itself can be ordered then delivered to a post office and finally, received by the client. Now, depending on the actual state, we want to print its delivery status. The simplest approach will be to add some Boolean flags and apply simple if/else statements within each of our methods in the class. That won't complicate it much in a simple scenario. However, it might complicate and pollute our code when we'll get more states to process, which will result in even more if/else statements. The state pattern is used in computer programming to encapsulate varying behavior for the same object based on its internal state. This can be a cleaner way for an object to change its behavior at runtime without resorting to conditional statements, and thus, improve maintainability.

The main idea of the state pattern is to allow the object to change its behavior without changing its class. Also, by implementing it, the code should remain cleaner without many if/else statements. The state design pattern is one of 23 well-known design patterns documented by the Gang of Four that describe how to solve recurring design problems. The state pattern is also known as objects for states. According to Wikipedia, the state pattern is a behavioral software design pattern that allows an object to alter its behavior when its internal state changes. This pattern is close to the concept of finite state machines. The state pattern can be interpreted as a strategy pattern, which is able to switch a strategy through invocations of methods defined in the patterns interface. As you see in this UML diagram, the state pattern has three participants. Context is an interface to client interact. It maintains references to concrete state objects, which may be used to define the current state of the object.

State is an interface for declaring what each concrete state should do. Concrete State provides the implementation for methods defined in state. So, the basic advantage of state pattern is to keep state specific behavior local and partitions behavior for different states. Also, the state pattern makes any state transitions explicit. That's all I have for now. Let's create a little project to help you understand better. Create a new project and call it State Pattern. The state pattern is one of the heavily used patterns in game development. The game character can be in different states such as healthy, surviving, and dead. When a character is healthy, it allows the user to fire at enemies with different weapons. When in surviving state, its health gets critical; and when its health reaches to zero, the character is said to be in dead state where the game is over. If we try to create this without using the state pattern, we will need numerous if/else blocks. So, let's create a project using the state pattern.

Let's begin. First, we need an interface named PlayerState that defines an action method. This method needs player class as parameter. Let's define the player class. In player class, we will define our methods as player's actions: attack, fireBomb, fireLaserPistol, fireGunBlade, survive, and the last one is dead. Done. Now, we need states. Let's start with the HealthyState, implement state. We have to override the method. Go on with SurvivalState. The last one is DeadState. Done. Let's define our context. First, a null state and a new player. We will change state, so we need set method. Also, we need an action to set the state to the player. Done. Our context is ready. Let's test our code.

First, we need a context instance. Set HealthyState. Call gameAction method. Now, change state with Survival. Call action, set DeadState. Done. Let's try and look at the result. As you can see, without any if/else block, we can create our structure. As a result, the state pattern in Java should be used if we have different behavior for each state of our object. Possibilities are we may need to configure the transition at runtime. It can come in handy in creating GUIs for a game as well. At runtime, the user may want a different interface for a particular level or the game itself might change the states according to the level of the game played. We have now finished the state design pattern. In the next video, we will examine the template pattern. See you in the next video.