All language subtitles for 007 State Pattern_en

So let's take a look at this rather complicated looking diagram.

It's not that complicated.

Trust me, I'm sorry, it's a little bit blurry.

This is taken from Wikipedia, where somebody has already done the work of putting this together for

me, and I think it's useful to evaluate some of the stuff from Wikipedia because the kind of diagrams

you're going to come across quite often.

So if you Google for state pattern, this is the kind of diagram that comes up.

So what is it saying?

Well, we have the idea of a context, which is we're coming from a finite state machine.

This is basically our finite state machine in here.

And then you have the state, except now the state is turned in instead of being an enum.

It is a an interface, is a class eight allows us to say this is an operation you can call this operation

on me.

And what will happen is that in this context, in the finite state machine, something happens and we

trigger, for example, the jump operation or the jump transition on the state.

And we don't actually know which concrete state we are in.

So you can have different states for the different states that inherit from the interface.

So state one, state two or jumping in air and ground, it could be three different subclasses and each

of them would implement their own version of Jump.

And then what happens is this is the little sequence diagram over here on the right.

So the context says, Hey, this operation.

So it could be saying, Hey, jump now state one could be ground.

It will say, OK, well set.

The state basically goes back and calls on the context again and says, Hey, go and set the state to

state to.

In this case, it's going to be to the jumping state.

And then the next song Operation comes in jump, for example.

Well, State two, which is maybe a jumping state, would ignore it and set or in this case, setting

it back to state one.

So that's a little bit elaborate from this pattern hierarchy.

Don't worry if you didn't get it from that, I just wanted to draw your attention to it.

And if you come back to this after we've had a look at some code, it might be a little bit clearer.

So here is an outline of what I've just been explaining.

We've got ourselves this locomotion state, which is an interface, as I said, and to implement this

interface, you need to implement the jump for all land and crouch transitions.

We're going to call the transitions to keep in line with our finite state machine that we saw in the

previous video.

You'll notice that they pass in this locomotion context.

We'll get to this in just a second.

But don't worry about it just yet.

It's essentially a state machine itself.

So then what does the state machine itself do?

Well, instead of keeping track of the enum, as I said, it's going to keep track of a locomotion state

that's referencing this interface here.

And whenever we get a crouch, full jump or land, it's just going to call Crouch full jump or land

on that current state, whatever that state currently is.

Now one problem here is that I haven't initialized that current state.

We do need to initialize it to something so we could set it equal to the new instance of and what states

do we actually have?

Well, you got a grounded state in our state and crashing state that override locomotion.

State interface.

Don't override.

Sorry.

That's the wrong word for interfaces.

They implement that interface so we can instantiate an instance of the Granite State.

So now at first blush, if we get a crouch events, we pass it on to the grounded state and we crouch

from within the Granite State.

So now let's go and have a look.

What happens if I crouch from within the Granite State?

Aha.

This is where that locomotion context comes in.

Essentially, what's going on is, we are saying, set the state on our finite state machine to be a

crouching state.

So new crouching state.

So that's what's going on here.

And ultimately, I find this so much easier to read.

If we're in the ground state and we crouch, we go to the crashing state.

If we're in the ground state and we fall, we go to the interstate.

We in the Granite State and we jump.

We go to the interstate.

If we land in the Granite State, well, nothing happens.

That kind of keeps us honest and make sure we don't forget about any of the transitions, because if

we had a new transition to the locomotion state to that interface, we have to implement it in each

of the states, even if it needs to do nothing, which is a nice mechanism for keeping us honest.

Now, I promised I'd circle back to this locomotion context interface.

So what have I done here?

There is another interface, and all it does is.

Have this set state function?

Why have I done that and why have I passed that in instead of the locomotion state pattern?

Well, two reasons, really.

The first one is I don't like circular references, so I didn't like the idea that we would have the

locomotion state pattern depending upon something like the grounded state and or the locomotion state

and then the locomotion state itself, depending back on the locomotion state pattern.

I don't like it when there is those circular references like that.

So there's generally it's not a good idea to have circular references.

It means things are very, very tightly coupled together.

So adding the locomotion context in here inverts those dependencies a little bit.

So locomotion state pattern depends on the context, and the state locomotion context depends only on

the state, and the state depends on the context of those two interfaces are linked to each other.

But that's all right when we're talking about interfaces.

So then the other reason for this is if I were to expose this locomotion state pattern to the wider

world and I want them to be able to call Crouch full jump land on here in order to manipulate this state,

perhaps in this finite state machine's internal state.

What I don't want is another public function here called set state, which would allow them to directly

manipulate the state of this nonno behavior.

So instead, by exposing it through an interface, we are saying you can only use this function if you

are using it via this interface.

So it just allows us to have a bit of interface segregation.

It makes it easier to not make the mistake of setting the state by accident directly and instead having

to use these transition functions instead.

Now we do have two more classes down here the interstate state and the crashing state, which you can

see haven't yet been implemented.

And you probably guessed it, that's going to be your challenge.

So here is the state machine again.

For reference, I've crossed out the Granite State and the transitions away from the ground state because

those have already been implemented.

So using those as a reference, go in, poke around with the code, get familiar with it and implement

the in-air and crashing states as well.

Post video and have a go.

OK, welcome back.

So hopefully this will be a bit easier because this is a more logical way of thinking about it.

So if we're in the inner state and we crouch, nothing's going to happen.

If we fall, nothing's going to transition, if we jump.

Nothing's going to happen.

So the only case where this actually does anything is in the land transition for the interstate state.

So that case, we're going to go to the context and set the state to be a new grounded state instance.

Like so now we go into our crouching state and we hit Crouch where we do want to do something and here

we want to take the context and set the state to a new grounded state instance.

Again, because we are going from crouching to grounded and ground and crashing and so on like that,

then we've got our fall.

What happens if we fall while we are crouching?

We're going to set the context set state to in and so new in our state.

If we jump, that is another state where we're just going to transition to ground, it's going to you

put that transition in there.

And if we land well, it does nothing.

We're already crouching.

We should be on the ground.

So landing shouldn't affect us.

So hopefully you can see how the state pattern makes it far easier to write this sort of code.

It also allows us to add in code.

Perhaps we could have update functions here within an individual state so that there's update functions

that are only running when you're crouching or update functions that are only running when you're in

the interstate allows us to segregate that code between the states much more easily.

In this example, I've put them all under one file.

Obviously, in reality, you would probably split each one of these, including the interfaces, into

their separate files.

But this gives you an idea of how you could use the state pattern for, in this case, locomotion.

You could use it for Ally like I was talking about, and you can implement all sorts of behaviors and

expand upon this immensely.

So if you do end up using the state pattern in your own code or you have already used the state patch

in your own code, please go and share in the discussions.

And let us know how you used it.

It would be really interesting to see this put to use in the wild by our students.