Hello, dear friends. In this video, we will examine The State Design Pattern. So, 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 would 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 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 can see in this UML diagram, the state pattern has three participants. Context is an interface to the client to 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 the state pattern is to keep state specific behavior local, and partition 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, just so you know. 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 it's 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 player state, that defines an action method. This method needs a player class as a parameter. Let's define the player class. In player class, we will define our methods as player's actions; attack, firebomb, fire, laser pistol, fire, gun blade, survive, and the last one is dead.

Okay, done. Now we need states. Let's start with the healthy state. Implement state. We have to override the method. Go on with survival state. And the last one is dead state. Okay, done. Let's define our context. First define a null state and a new player. We will change states, so we need set method. Also, we need an action to set the state to the player. Okay, done. Our context is ready. Let's test our code. First we need a context instance. Set healthy state. Call game action method. Now change state with survival. Call action set dead state. Okay, done. Let's try and look at the result.

As you can see, we can build our structure without using any if/else blocks. As a result, the state design pattern in Java should be used if we have different behavior for each state of our object. It's possible that we will need to configure the transition at runtime, and it can come in handy for creating GUIs for games 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. So, now we have finished the state design pattern. We will examine the template pattern. So I'll see you in the next video, my friends.