So state it's one of those bizarre design patterns in that if you look at the classic definition of
the state design pattern you're going to see something very different from how we actually build state
machines nowadays so it's a completely different paradigm and I am going to show it to you because I
think it has to be shown for completeness but I do think that it's not something that you should be
doing necessarily in code because the kind of classic design pattern and implementations that you see
out there are just not very realistic to be honest so let's imagine that we want to model a very simple
situation of switching the light on and off in the room.
So typically what you would do is you would define a base class called state and then you would define
inherit as such as the state and the state.
So we'll have on state and will simply have the state.
Now I have to say that in this particular scenario you can just do away with a simple enough but we're
doing this kind of Object-Oriented paradigm for completeness sake.
So I'm having actual classes here.
OK.
So let's suppose that we now want to have a constructor in each of the states to actually indicate we
want to do something.
So in the on state constructor I'm going to say that light is turned on.
And similarly for the All-State
we shall have five-Test turned off.
OK so that's the construct.
Another question is how do you switch from one state to another.
And for that you need a light switch.
So that's another class called light switch.
And here we're going to have a pointer to the current state and a couple of public members so we're
going to begin by having the state in the state like so and then we're going to sort of switch from
one to another so we'll have some utility function for switching the state.
So I'll have void set States which takes a state pointer state and we simply say this state equals thing.
That's how we can switch from one to another.
And now of course we can have utility functions called on and off which actually switch the state but
their implementation in the classic state design pattern are very strange.
So let's go back to the top of our hierarchy and look again.
So let's suppose that we define virtual functions called on and off.
Right inside the state virtual void on which takes light switch pointer and we'll have a similar function
called off.
Notice I'm not making a view of show but I'm not putting in anything in there just yet.
We will do it in just a second.
So here's the idea.
You take each of the states and you basically have to override these functions but you only want to
override the function which is the opposite of what you're in.
So if you're in the on state you want to override the function if you're in the off state you want to
override the on function thereby allowing some sort of interface for switching from this particular
state to the other state.
So here I would say I would do an override.
So if we go and actually override functions I would override the function here.
Like so and symbole in this particular case I would override the off the on function rather like so
let's actually get rid of their implementation because I'm going to have those things generated later.
So let's let's generate the implementation.
I was actually hoping the line would help.
There we go.
So get rid of this and then I will generate this one as well and generate the implementation of on and
I would just stick them somewhere to the very end and stick them down below to to the very end of our
file.
So to come in here maybe and grab this one as well.
OK.
So what are these functions going to do well first of all we'll just have some output.
So here I'm going to say switching light off and then when I'm going to do is I'm actually going to
take the light switch and I'm going to use the light switch to set it to and you state.
So essentially I'm going to say that well why is it.
LH wrestlers actually rename this it should be just switch or something to that effect switch.
There we go does this propagates insert that identifier in it.
Well that's not nice.
Counsel let's try something else.
LS Not very imaginative.
So we're going to have ls here less here as well.
Let me just verify that all they have to propagate it.
That's annoying.
I was hoping them to propagate everywhere but evidently not.
OK so we have the on and off on the state and the implementation is actually we are using the light
switch.
So in the lights which you call set state and you specify in you all state in this case and the same
would go for the on state and then of course you can also delete the current state.
Delete this.
This is one of the few cases in like C++ where you are actually going to see delete this.
There are some uses of it in the Microsoft Foundation Classes for example.
Generally any time I see Dilley this it's it's a red flag it's something that's just bizarre.
I mean I know it's valid I know you can delete yourself.
There was no problem in it.
But whenever you see it you should be concerned.
So we sent someone to replicate this and I'm going to copy it here.
So here we are switching the light on and we're setting it to be on stage here.
So this is the setup that we have so far and now we can implement the on and off functions on the actual
light switch because all they do is they use the on and off functions of the state interestingly enough.
So essentially we have the state and we see a state on passing this and the same goes here.
Stay off passing this.
Now you're probably wondering.
Well hold on.
If we're in the on stage for example when we call off everything is fine because if we're in the on
state and we call off we have an implementation.
But if we are already in the on state and we call on them once again.
What do we do.
Well you'll notice that these functions on the show and as a result if we're already in the on state
we can actually put the implementation on in here so we can say oh by the way the light is already on
hand.
We can do the same here.
So light is already off.
There we go.
So putting all of this together we can now experiment with this set up and actually try switching the
lights.
Here is a light switch when I'm going to instantiate the actual States at any point in time we're only
using the light switch.
So I say light switch on light switch off and then light switch off again just to see some of the code
related to the complaint that by the way it's already off.
Why are you trying to switch it off again.
So let's run this in and see what we get.
All right.
So let's take a look at how this matches what we already have.
So we have the light switch and we call light switch on.
So initially the light switch is off.
That's why we get this outputs.
So when we call light switch on we're switching the light on and the light is on then we're switching
it off and the light is off.
And the last one that's the interesting one the light is already off.
So we're not in the process of switching it again because well it's already often that's where the kind
of base class of virtual members fire.
Now this whole approach this whole paradigm the way the states are set up here is really weird.
The idea that you have every single individual state allowing functions to be called on it to switch
to a different state but the implementation of these functions of where you basically set the new state
on this kind of effectively a mediator in this case and then calling delete this is not how we do things
in the real world.
So it is a workable example it is an example that you're going to see in books and online but it's not
an example that I would personally recommend.