I usually watch various tutorials, so I feel capable of giving a "competent" judgment: you have excellent presentation, comprehensive, organized, straight to the point, more than valid expertise, but what struck me is your enthusiasm and eagerness to convey competence. You deserve a like and a subscription. Thank you for your effort.
Can I just take a moment and appreciate your efforts here! You made design pattern really understandable for me! Hats off to your efforts 🙏🤗 Wish you get everything required to be able to continue this series as well. Take care Christopher :)
"Replace a conditional with polymorphism" - this will be my new favorite quote from the entire design pattern playlist kek ~ (the same concept used first in composite pattern)
that was a GREAT video! Chris, we're missing your videos on design patterns and different topics really bad! I hope you can find more time in the near future to help us learn more and become better software developers. Much love!
I’m super glad to hear you feel that you’re learning faster :) I like to think that the quicker we can get the “known things” out of the way, then we can start to think about the “unknown things”. Which imho is where the really interesting issues lie :)
There was a similar example in a textbook I used to teach Java which used three states LOCKED, UNLOCKED, and ROTATING. The transitions were "payment" for LOCKED --> UNLOCKED, "push" for UNLOCKED --> ROTATING, and "one revolution" for ROTATING --> LOCKED.
you are perfect, i have only a few hours before exam i tried to watch 2x speed but it is still perfect because of body language, fluently speaking, diving into everything with clear explanation. need to say that i am still trying to learn english but i understand whole video. THANK YOU A LOT FOR YOUR EFFORT AND AMAZING JUMP CUTS.
I have been searching for Design pattern tutorials online like forever, to find something that can be more relatable to the software systems. But all I ever find are Ice cream, Pizza, Burger examples, which makes no sense what so ever. Thank you so much for all your efforts and making sense. I feel I am a better Software Engineer than I was 1:20 Hrs ago.
Hey man, I just found your channel. Immediately I knew I liked you, and it took me a while to figure it. It's cuz you look like Antonio Banderas! Your energy also is amazing! So much alive and warm :) I'm a smart guy, but as soon as I build a game that has all the basic elements . . .I get lost in the jungle of the code. So I started reading about design patterns. Well, my friend. You're the first one that I can follow! And even understand to that point that I can really see what you drew on your whiteboard as beautiful! Please keep making such simple videos and stop for so many explanations! :) :) :) Thank you man! p.s. Headfirst book sounds like a thing for me Love from Croatia!
I've studied your videos for a while, and come back to them. But, I find it's only when I actually need to use a certain pattern that your videos make sense to me. I need to use the state pattern for game development and this video has been a God send. Thank you so much.
What a explanation 🙌🙌 guys if you are confused whether to watch or not seeing the video duration, just give it a try. As otherwise you will have to waste double the time while reading articles
I think that I've used it in a functionality where I manage a events system where there are subscription of people to participate... and the subscription have state : open, running and closed... where depends on your state some objects will be handled of different ways.
I developed a POS (point of sale) cashier app using the state pattern, seems the only practical choice. Your video is good and refreshing, our support developers definitely should go through this video before reading the POS code.
I build simple 2d game on JS. Decide to implement player state via state pattern. State like `idle`, `jumping` etc. By the way game examples is often easer to understand, when you explaining programming concepts. There is one interesting book, which I read recently "game programming patterns", maybe you will like it
Nice one, but I disagree with passing the gate reference. If the interface for a state declares that an action causes a state to generate a state (e.g return GateState), you can avoid passing references to the gate itself, and from your gate call the action on the state to return a new state, and assign it to your ivar locally. Other than that, I like this playlist. For each pattern, I created a swift playgrounds version for future reference. I wasn't aware I was using so many of them :) Keep up the great work!
Hi, Could you if possible share your playgrounds files? I loved your solution about how to create a new State, just returning a State on each function, but if you are doing an async request probably you have to wait this new state, so probably call a delegate like changeState is better for a reactive approach.
what if the action we wanna do actually does produce a result and returns it like for example the payOk should return the payment id or something ... in that case the return type could not be just the new state .... . . . . . . . maybe you could specify the first returned item to be the new state and the other results to be the other stuff you are expecting from the method ...
I really like how you explain things (and sometimes go to other related things and go back). I thought I was the only one who explained things in this way! Thanks a lot for your videos.
As suggested in some comments, I would rather return the next state to the gate, from the states "action" methods, something like "nextState = currentState.actionPerformed()" (instead of a void return)
That would be helpful if you are returning void but if you are returning some response then you cannot return state. There should be a signalling mechanism to change state i.e one state should signal the parent gate to change state. And for states there should be a factory that creates these states
Thank you so much for providing so many awesome videos. Even though I am unable to fully understand or master each every pattern, but you gave me the courage to dive deep into OOD. I will definitely read these two books again. Thank you !!!!
Regardless of mutability, I would not store a Context (Gate) reference on all States. That creates a stronger bind between the Context and the State than simply using the context with needed (and then discard). With this in mind, I would simply pass the Context to each of the State interface methods so that the concrete State could then use the context to set the new (current) state.
Dang! This is the best of ALL the videos so far! I really thought I just knew this pattern inside out... and still the devil is in the detail... I'm saddened that it doesn't have more views, ALL developers should be forced to watch this :)
I was thinking the same thing. He makes things ten times easier to understand. And I also think that all developers out there must watch this design patterns series.
Hi, many thanks for the video I' ve learned a lot, appreciate that. My question or maybe suggestion, would you consider to change the names, to turn the names of the states e.g. OpenGateState => GateStateOpen, ClosedGateState => GateStateClosed etc. because int this way it's even more clear that they belong together.
It's great how you can describe things on the desk, but I guess the coding part can be done in textEditor or smth. With splitscreen so every class would be visible to a viewer at the same moment of time. The code would be much cleaner and readable thus. Means = more understandable
I think the key idea of this pattern is around 42:50~43:35, delegate the functionality that relies on the state to the State object instead of the Context Object and use polymorphism
I really like the idea that sometimes I don't get it the first, but then he tries to rephrase what he's saying or puts in a different way or with a different example, and then it starts to make sense to me. That's a lot of effort in explaining. He should become a professor or something.
Dear Sir, at 1:02:47 inside the OpenGateState once we pass payOk() shouldn't it stay in the OpenGateState only? Why have u passed the changed state() and changed it to closed state? ClosedGateState will only come if I pass enter() in the class definition of OpenGateState? Kindly clarify.
great content, used to watch your videos years back, and now again. i noticed a small mistake but its not a big detail: in 7:10 u mention that if youre in the openstate and you receive a payOk message you stay in the Openstate, but in 58:11 youre giving an example for when youre in the openstate and you receive a payOk you close the gate. i think you accidently overlooked it
Hi Christopher, first thanks for your explanations it helps a lot. I did not check the other comments, then I will give you my question (4 years later ^_^') Each time a state is changed by a handler by the changeState method. And through this method a new instance of State object is created. So here is the point: how the older state instance is deleted ? I suppose it depends of the languague we use but in some examples, a static instance is used
Thank you so much for the wonderful explanation Chris!! Looking forward to more design pattern videos from you... for Builder/FlyWeight/ChainOfResponsibility/Memento/Mediator/Visitor may be? :)
I like It a lot, a bit longer than expected, but perfectly understood, this is a pattern very used in React, but this video is very useful to use It better
Would it make sense to implement the singleton pattern on each state so that we do not need to instantiate thousands of states and just use the one we need ? You would pass the gate as an argument for each method but you would only have a single instance of each states and gates would still use the one they need individually. I know you've said that we should avoid using the singleton pattern but if the object instantiated is just a library of methods there's no reason to duplicate it... is there ?
Wouldn't this be a problem if we have multiple gates? In that case we need multiple instances of GateState ? May be we can have a factory as part of Gate which always return reference to same object. This way each GateState can ask for GateState object from Gates factory. This will also avoid the problem that you pointed(recreating objects) but also allows multiple gates in system.
I have a doubt here. 1) While transitioning states, we are always creating a new instance of next State object. Is this a good idea ? 2) Is it possible to create all possible State objects just once and store it in the Context Class (Gate class here). Since we are already passing the Gate class to the GateState class, we can just get the next State object from the pre-created objects instead of creating a new one every time ? 4) If yes, can you give a correct way of implementing above thing.
I realize you asked your question a year ago.. If you were to hold an instance of every (currently known) state in your context class, you'd be setting yourself up for problems down the line when new states are introduced or naming changes or certain states are no longer part of the solution. Keeping the states decoupled from the gate class allows any state to be implemented at any time during the life of the program without having to screw up your context class.
Pretty good explanation. Thanks Chris. May be this needs a better example since 2-state machines don't really need a State Pattern but a boolean and we may be abusing the design pattern (aka Design smell) in our code.
I have a question, considering the initial discussion when we decided that in the OPEN GATE STATE if we try to pay again we would remain in that state (even if the payment is succesful or not), the concrete implementation is ok? Im a bit confused
The concrete implementation is wrong in the video. PayOk is what gets you in the open state to begin with so if you get payOk when already in the open state, it’s a signal of an attempted double payment and so, the gate should stay open and not close. The enter event is what causes the gate to go from open to closed.
That’s a reference type right , so which is pointing to the address of that object (gate in example) . So, when you use it in concrete gate state , it would have fully constructed and you can use all the properties and methods .
> Interesting: we've modeled the state and how it responds to different events, but we have not modeled how the events themselves are triggered. That will be the business logic tied up with the idea of 'Context'.
I'm feeling weird about the idea that the state provides a new state to the state machine. Shouldn't there be a contract (ie. interface) between the state machine and the state where the state can use GoToOpenState() rather than creating a dependency between the concrete OpenState and CloseState? I mean if I'm a state, I shouldn't be responsible for instanciating the next state, rather I should tell the state machine that now it should transition to the state Open, however is has been defined.
I think you have an error, or may not, correct me if i'm wrong but, When your Gate is on state open and you receive the method payOk() you should stay on open state, right?
I think you're right. payOk() in OpenGateState should just do nothing. Imo the given implementation should be for the enter() method. This also doesn't change for the first, simpler version of the state machine.
Thank you for your explanation. It was especially useful to hear about state diagrams and to see them used in the explanation of the UML. Your method of repetition seems to really help link your different parts together. I did have one question that I may attempt to experiment with myself and that is why a concrete state object wasn't returned from the action/message handler methods and used to set a reference in the context?
Your videos are amazing. I enjoyed every bit of them. There is not a lot of good tutorials on advanced OOP on UA-cam. Can you please consider making some?
If you wanted to avoid mutation and dependency injection, would you just make the interface methods be of type GateState and say state = state.enter(), for example?
What are the differences between a state machine and the state design pattern? Or why a state machine is not a 100% representation of the state design pattern? Thanks!
Mixed feelings. After I watched this video, I felt that injecting the Context (Gate) into the State is unnecessarily complex. It would be simpler and more explicit to return the new State from each handle (and simply return "this" if we stay in the same state) and the Context request methods are responsible for applying that returned state. Then I realized that the pattern is not only about states and transitions; the states also do something for each handle, that is, they manipulate data. And this data resides in the Context (preferably in a third class, say, Data). So it is necessary to inject Data into the State. And I think I'd prefer to do this as an argument to the handles. So, to sum up, I think I would prefer to have "State handle(Data data)" methods instead of "void handle()". Do you see any downsides? PS: So far I have implemented all my state machines using enums and switch(). I wonder if I really try the State Pattern next time.
Really aweaome way of explaining concepts. More than that tge passion you show is tremendoua. Thanks for sharing uour knowledge. One question i had was ...why is pay part of gate class after paymentbdoes not happen on a gate. Having payok makes sense but not pay. Isnt it?
learned a lot from this video, Thank you... I have a doubt, why cant we return state itself . How about changing player state outside of the state class, e.g gate.state = gate.state().enter(); - - - -- -- - - in our main class
This could be a solution, but we might want to encapsulate the inner working of the gate. The user (programmer who uses the gate / programmer) shouldn't need to know the internals of the gate or even that it is a state machine. Also, if for whatever reason you decide to change the interface of how the State works you need to make changes in a lot of places in you program vs changing just the Gate class.
@59:12, why are we calling changeState when in open gate state and even is payOk? when we are already in open state and we get enter event then we should move to closed state right? (as per diagram too) I mean eventually the state shouldn't change. State transition from open to close happens only when we get the "enter" event! please correct me. @1:14:20, I should develop more patience.
I've devoured your entire playlist and now I'm sad cuz there aren't any design videos of such quality and engagement on the internet :( What about resuming the series?
Wow! this is a jewel :) I would be using state pattern with my upcoming project and this video explains everything on topic. Excellent video. Keep the great work up (Y) I would like to hear your opinions on Inversion of Control and Dependency Inversion principle from SOLID. I am super confused between these two and can seem to make distinction between them. They look same to me
Maybe I missed it, but what about methods on your context who do not transform state but are only affected by state? Would I also delegate this first to the state object or just put a condition check if I'm in the right state? Something like setName() in on a document object which is only allowed in a certain editable state?
Hi Christopher, great videos and playlist. It helps me a lot to appropriate design patterns. About the State Pattern, it kinda looks like the Strategy Pattern as each state has its own logic, right? I would define the State Pattern as an evoled Strategy Pattern. Do you agree? Do you consider make a new video in this playlist to explain the difference(s) between these two? Thanks again :)
Hi Christopher, first thanks for making this series. I actually have questions regarding state pattern around 1:11:15. I see that whenever you change state you initiated a new state. I think for the same gate, if it opens, closes, and repeat, it should reuse the existing state. Am I wrong? I don’t understand the potential benefit of countinuous instantiation. Any light shed on my confusion would be appreciated.
Great video! I have been struggling to understand State Pattern but you made it really clear! I’m not very sure but the sample code you provided seems to be impossible to instantiate (apologies if I’m wrong) The reason is that the Gate class requires GateState object in the constructor while GateState requires Gate object in its constructor. It looks like circular reference, would it be possible to instantiate? (I’m gonna test it out when I’m available)
Hi Christopher, I have a suggestion regarding this pattern. I think methods in State interface can be of return type State instead of void & inside gate class or the context, whenever delegating to the Concrete State Classes we assign the return State like - "this.state = this.state.payOk();" and (return this) or create the required ConcreteState Object in Concrete State methods. and this adds only one assignment in every method of context. BTW Awesome Videos, Best Videos on OOP & design patterns on Internet, & lots of Thanks from India.
He actually mentioned this type of implementing the pattern at 49:30 in the video. It sounds like a neat concept at first but if we were to use the design example from the headfirst on using a gumball machine, the dispense method should be handled by the gumball machine and not the states. So it wouldn't be easy to call Dispense from TurnCrank because we have no reference to the base class. Also the base class may need to set its own state as well.
An 80 minute video on a design pattern?!
It really is Christmas, thanks Chris
Thank you and Thank you for watching 🙂🙂
singleton pattern is 20 minutes!!! :)
wtf is wrong with u
@@TheGGbond reversed card actually
I usually watch various tutorials, so I feel capable of giving a "competent" judgment: you have excellent presentation, comprehensive, organized, straight to the point, more than valid expertise, but what struck me is your enthusiasm and eagerness to convey competence. You deserve a like and a subscription. Thank you for your effort.
People don't understand the hard work puts for +1h explaining design pattern + editing, thank you 👌
only with these videos I've aced the design patterns exam . Thank you .
What exam?
Can I just take a moment and appreciate your efforts here!
You made design pattern really understandable for me! Hats off to your efforts 🙏🤗
Wish you get everything required to be able to continue this series as well. Take care Christopher :)
36:00 definitions
51:23 code
"Replace a conditional with polymorphism" - this will be my new favorite quote from the entire design pattern playlist kek ~
(the same concept used first in composite pattern)
that was a GREAT video! Chris, we're missing your videos on design patterns and different topics really bad! I hope you can find more time in the near future to help us learn more and become better software developers. Much love!
Watched at 2x speed; it's doable as I've some pre-existing knowledge of this pattern and this video makes a great refresher. Thank you very much.
You do a very good job in visualising these problems. Thank you, I'd be in trouble with my design pattern course without you.
I’m super glad to hear you feel that you’re learning faster :) I like to think that the quicker we can get the “known things” out of the way, then we can start to think about the “unknown things”. Which imho is where the really interesting issues lie :)
There was a similar example in a textbook I used to teach Java which used three states LOCKED, UNLOCKED, and ROTATING. The transitions were "payment" for LOCKED --> UNLOCKED, "push" for UNLOCKED --> ROTATING, and "one revolution" for ROTATING --> LOCKED.
you are perfect, i have only a few hours before exam i tried to watch 2x speed but it is still perfect because of body language, fluently speaking, diving into everything with clear explanation. need to say that i am still trying to learn english but i understand whole video. THANK YOU A LOT FOR YOUR EFFORT AND AMAZING JUMP CUTS.
This is a really nice tutorial. Please keep it going. I am kind of addicted to your videos now.
I have been searching for Design pattern tutorials online like forever, to find something that can be more relatable to the software systems. But all I ever find are Ice cream, Pizza, Burger examples, which makes no sense what so ever.
Thank you so much for all your efforts and making sense.
I feel I am a better Software Engineer than I was 1:20 Hrs ago.
Hey man, I just found your channel.
Immediately I knew I liked you, and it took me a while to figure it.
It's cuz you look like Antonio Banderas!
Your energy also is amazing! So much alive and warm :)
I'm a smart guy, but as soon as I build a game that has all the basic elements . . .I get lost in the jungle of the code. So I started reading about design patterns.
Well, my friend. You're the first one that I can follow! And even understand to that point that I can really see what you drew on your whiteboard as beautiful!
Please keep making such simple videos and stop for so many explanations! :) :) :)
Thank you man!
p.s. Headfirst book sounds like a thing for me
Love from Croatia!
I've studied your videos for a while, and come back to them. But, I find it's only when I actually need to use a certain pattern that your videos make sense to me. I need to use the state pattern for game development and this video has been a God send. Thank you so much.
the best patterns explanation I've come across so far
What a explanation 🙌🙌 guys if you are confused whether to watch or not seeing the video duration, just give it a try. As otherwise you will have to waste double the time while reading articles
I watched tons of video about DP, your DP playlist make you special among the bests Chris!
Question of the day: Have any examples of where you successfully used the state pattern?
I think that I've used it in a functionality where I manage a events system where there are subscription of people to participate... and the subscription have state : open, running and closed... where depends on your state some objects will be handled of different ways.
I developed a POS (point of sale) cashier app using the state pattern, seems the only practical choice. Your video is good and refreshing, our support developers definitely should go through this video before reading the POS code.
Used it in a VR app, where the Input of the User needed to cause different things to happen depending on the current state.
I build simple 2d game on JS. Decide to implement player state via state pattern. State like `idle`, `jumping` etc. By the way game examples is often easer to understand, when you explaining programming concepts. There is one interesting book, which I read recently "game programming patterns", maybe you will like it
Games.
AI.
Nice one, but I disagree with passing the gate reference.
If the interface for a state declares that an action causes a state to generate a state (e.g return GateState), you can avoid passing references to the gate itself, and from your gate call the action on the state to return a new state, and assign it to your ivar locally.
Other than that, I like this playlist. For each pattern, I created a swift playgrounds version for future reference. I wasn't aware I was using so many of them :)
Keep up the great work!
Hi, Could you if possible share your playgrounds files?
I loved your solution about how to create a new State, just returning a State on each function, but if you are doing an async request probably you have to wait this new state, so probably call a delegate like changeState is better for a reactive approach.
As I remember, he mentioned that possible solution before the coding part:)
what if the action we wanna do actually does produce a result and returns it like for example the payOk should return the payment id or something ... in that case the return type could not be just the new state ....
.
.
.
.
.
.
.
maybe you could specify the first returned item to be the new state and the other results to be the other stuff you are expecting from the method ...
I really like how you explain things (and sometimes go to other related things and go back). I thought I was the only one who explained things in this way! Thanks a lot for your videos.
As suggested in some comments, I would rather return the next state to the gate, from the states "action" methods, something like "nextState = currentState.actionPerformed()" (instead of a void return)
That would be helpful if you are returning void but if you are returning some response then you cannot return state. There should be a signalling mechanism to change state i.e one state should signal the parent gate to change state. And for states there should be a factory that creates these states
@@abhishekjain3527 you should return the new state and use "signalling mechanisms" for "some response", not the other way around
The way of your teaching is very interesting and helpful. Thanks for your effort.
Only 72 comments? Here one more to appreciate your hard work and effort!
Thank you so much for providing so many awesome videos. Even though I am unable to fully understand or master each every pattern, but you gave me the courage to dive deep into OOD. I will definitely read these two books again. Thank you !!!!
I’m glad to hear :) Thanks for commenting!
This has been very enlightning! Very well explained with the exact amount of detail, thanks a lot!
Good explanation of the concepte and theory of the State Design Pattern, when rarely found in UA-cam. (y)
The best explanation of this pattern in the internet still 2020
Amazing explication. I loved it. Congrats Chris. Great video. Thank you very much.
Regardless of mutability, I would not store a Context (Gate) reference on all States. That creates a stronger bind between the Context and the State than simply using the context with needed (and then discard). With this in mind, I would simply pass the Context to each of the State interface methods so that the concrete State could then use the context to set the new (current) state.
great sound effects. the "boop" sound is to die for.
Dang! This is the best of ALL the videos so far! I really thought I just knew this pattern inside out... and still the devil is in the detail... I'm saddened that it doesn't have more views, ALL developers should be forced to watch this :)
I was thinking the same thing. He makes things ten times easier to understand. And I also think that all developers out there must watch this design patterns series.
looking fierce bro! Thanks, you explain very well. ….. 25 more minutes in and damn even more impressed. I subscribed, thanks for teaching,
I love this entire series. Fantastic!
It is a very informative content, presented nicely. I like your videos and the way you explain things. Keep up the good work Chris 👍😊
Great teaching and information. Thank you very much!
Thank youuuu sooo muchhhhhhh ! your the best way to understand the concrets concepts of DP
Really really good tutorial. Greetings from Poland:)
Hi, many thanks for the video I' ve learned a lot, appreciate that. My question or maybe suggestion, would you consider to change the names, to turn the names of the states e.g. OpenGateState => GateStateOpen, ClosedGateState => GateStateClosed etc. because int this way it's even more clear that they belong together.
It's great how you can describe things on the desk, but I guess the coding part can be done in textEditor or smth. With splitscreen so every class would be visible to a viewer at the same moment of time. The code would be much cleaner and readable thus. Means = more understandable
I think the key idea of this pattern is around 42:50~43:35, delegate the functionality that relies on the state to the State object instead of the Context Object and use polymorphism
i literally love you for these videos
This channel is such a blessing.
Thank you so very much Chris.
I really like the idea that sometimes I don't get it the first, but then he tries to rephrase what he's saying or puts in a different way or with a different example, and then it starts to make sense to me. That's a lot of effort in explaining. He should become a professor or something.
This was amazing, I learned alot. Thank you Christopher :-)
Once again.. another Great Video . Kudos to you.
Dear Sir, at 1:02:47 inside the OpenGateState once we pass payOk() shouldn't it stay in the OpenGateState only? Why have u passed the changed state() and changed it to closed state? ClosedGateState will only come if I pass enter() in the class definition of OpenGateState? Kindly clarify.
I will be your patreon if you start making videos again, you have my word.
Best design pattern videos 🙌
Thank you so much for your passionate work!
great content, used to watch your videos years back, and now again. i noticed a small mistake but its not a big detail: in 7:10 u mention that if youre in the openstate and you receive a payOk message you stay in the Openstate, but in 58:11 youre giving an example for when youre in the openstate and you receive a payOk you close the gate. i think you accidently overlooked it
Hi Christopher, first thanks for your explanations it helps a lot. I did not check the other comments, then I will give you my question (4 years later ^_^')
Each time a state is changed by a handler by the changeState method. And through this method a new instance of State object is created. So here is the point: how the older state instance is deleted ? I suppose it depends of the languague we use but in some examples, a static instance is used
One of the best explanation! Thank you very much!
Very useful and clear even for a soil scientist like me!
Thank you so much for the wonderful explanation Chris!! Looking forward to more design pattern videos from you... for Builder/FlyWeight/ChainOfResponsibility/Memento/Mediator/Visitor may be? :)
last repetition before exam, great job :D thanks
Glad to hear it helps :) Best of luck on the exam! :)
Hey Chris. Thanks for these invaluable content. One request. Could you please do a video on Interpreter design pattern? Thanks mate.
excellent video, you have the gift of teaching! subbed
Thank you so much for these videos!
You are a great teacher!
I like It a lot, a bit longer than expected, but perfectly understood, this is a pattern very used in React, but this video is very useful to use It better
Would it make sense to implement the singleton pattern on each state so that we do not need to instantiate thousands of states and just use the one we need ? You would pass the gate as an argument for each method but you would only have a single instance of each states and gates would still use the one they need individually. I know you've said that we should avoid using the singleton pattern but if the object instantiated is just a library of methods there's no reason to duplicate it... is there ?
Wouldn't this be a problem if we have multiple gates? In that case we need multiple instances of GateState ?
May be we can have a factory as part of Gate which always return reference to same object. This way each GateState can ask for GateState object from Gates factory. This will also avoid the problem that you pointed(recreating objects) but also allows multiple gates in system.
I have a doubt here.
1) While transitioning states, we are always creating a new instance of next State object. Is this a good idea ?
2) Is it possible to create all possible State objects just once and store it in the Context Class (Gate class here). Since we are already passing the Gate class to the GateState class, we can just get the next State object from the pre-created objects instead of creating a new one every time ?
4) If yes, can you give a correct way of implementing above thing.
You can use Singleton Pattern for each state: ua-cam.com/video/hUE_j6q0LTQ/v-deo.html
I realize you asked your question a year ago.. If you were to hold an instance of every (currently known) state in your context class, you'd be setting yourself up for problems down the line when new states are introduced or naming changes or certain states are no longer part of the solution. Keeping the states decoupled from the gate class allows any state to be implemented at any time during the life of the program without having to screw up your context class.
Very good stuff. Thanks man!
Pretty good explanation. Thanks Chris. May be this needs a better example since 2-state machines don't really need a State Pattern but a boolean and we may be abusing the design pattern (aka Design smell) in our code.
You never can tell, it could grow beyond that
I have a question, considering the initial discussion when we decided that in the OPEN GATE STATE if we try to pay again we would remain in that state (even if the payment is succesful or not), the concrete implementation is ok? Im a bit confused
In the paymentOK method we switch to a closed gate state
The concrete implementation is wrong in the video. PayOk is what gets you in the open state to begin with so if you get payOk when already in the open state, it’s a signal of an attempted double payment and so, the gate should stay open and not close. The enter event is what causes the gate to go from open to closed.
Passing "this" from inside the constructor is not a good idea, since the object is not fully created until the constructor returns.
But then how to create the initial state?
That’s a reference type right , so which is pointing to the address of that object (gate in example) . So, when you use it in concrete gate state , it would have fully constructed and you can use all the properties and methods .
> Interesting: we've modeled the state and how it responds to different events, but we have not modeled how the events themselves are triggered. That will be the business logic tied up with the idea of 'Context'.
Now it`s all clear, thanks !
I'm feeling weird about the idea that the state provides a new state to the state machine. Shouldn't there be a contract (ie. interface) between the state machine and the state where the state can use GoToOpenState() rather than creating a dependency between the concrete OpenState and CloseState? I mean if I'm a state, I shouldn't be responsible for instanciating the next state, rather I should tell the state machine that now it should transition to the state Open, however is has been defined.
I think you have an error, or may not, correct me if i'm wrong but,
When your Gate is on state open and you receive the method payOk() you should stay on open state, right?
I think you're right. payOk() in OpenGateState should just do nothing. Imo the given implementation should be for the enter() method. This also doesn't change for the first, simpler version of the state machine.
Thank you for your explanation. It was especially useful to hear about state diagrams and to see them used in the explanation of the UML. Your method of repetition seems to really help link your different parts together.
I did have one question that I may attempt to experiment with myself and that is why a concrete state object wasn't returned from the action/message handler methods and used to set a reference in the context?
Your videos are amazing. I enjoyed every bit of them. There is not a lot of good tutorials on advanced OOP on UA-cam. Can you please consider making some?
If you wanted to avoid mutation and dependency injection, would you just make the interface methods be of type GateState and say state = state.enter(), for example?
Thank you, dude! Useful and comprehensible tutorial)
Thanks! Im glad to hear! And thanks for watching :)
What are the differences between a state machine and the state design pattern? Or why a state machine is not a 100% representation of the state design pattern? Thanks!
Mixed feelings.
After I watched this video, I felt that injecting the Context (Gate) into the State is unnecessarily complex. It would be simpler and more explicit to return the new State from each handle (and simply return "this" if we stay in the same state) and the Context request methods are responsible for applying that returned state.
Then I realized that the pattern is not only about states and transitions; the states also do something for each handle, that is, they manipulate data. And this data resides in the Context (preferably in a third class, say, Data). So it is necessary to inject Data into the State. And I think I'd prefer to do this as an argument to the handles.
So, to sum up, I think I would prefer to have "State handle(Data data)" methods instead of "void handle()". Do you see any downsides?
PS: So far I have implemented all my state machines using enums and switch(). I wonder if I really try the State Pattern next time.
In this example one could need a method similar to "typeof" to determine current state by it's class name and than apply conditional algorithm.
@@kotekutalia so maybe a Generic?
Really aweaome way of explaining concepts. More than that tge passion you show is tremendoua. Thanks for sharing uour knowledge.
One question i had was ...why is pay part of gate class after paymentbdoes not happen on a gate. Having payok makes sense but not pay. Isnt it?
Great work 👏
learned a lot from this video, Thank you...
I have a doubt, why cant we return state itself .
How about changing player state outside of the state class,
e.g gate.state = gate.state().enter(); - - - -- -- - - in our main class
This could be a solution, but we might want to encapsulate the inner working of the gate. The user (programmer who uses the gate / programmer) shouldn't need to know the internals of the gate or even that it is a state machine. Also, if for whatever reason you decide to change the interface of how the State works you need to make changes in a lot of places in you program vs changing just the Gate class.
@59:12, why are we calling changeState when in open gate state and even is payOk?
when we are already in open state and we get enter event then we should move to closed state right? (as per diagram too)
I mean eventually the state shouldn't change.
State transition from open to close happens only when we get the "enter" event!
please correct me.
@1:14:20, I should develop more patience.
This is amazing, really great
Thank you
I think that this payOk() method in OpenGateState should be the enter(). Thanks for your work.
007arek t le boss toi j ai pose la mm qst 😂😂, enfin j ai trouvé un commentaire qui partage la meme idee
Correct
wonderful series!
The Gate class has a set of methods with the same signatures as the GateState interface. Then, coudn't Gate also implement GateState?
@19:00 min how the state open become remain open when PayFailed?
I've devoured your entire playlist and now I'm sad cuz there aren't any design videos of such quality and engagement on the internet :( What about resuming the series?
What is the way to remove the circular dependency of GateState on Gate? and of Gate on GateState?
Great video and channel I like it very well
Wow! this is a jewel :) I would be using state pattern with my upcoming project and this video explains everything on topic. Excellent video. Keep the great work up (Y)
I would like to hear your opinions on Inversion of Control and Dependency Inversion principle from SOLID. I am super confused between these two and can seem to make distinction between them. They look same to me
I like this video will check your other videos for sure
wow this is an amazing tutorial thanks man
This was good, I learned alot. Thank you!
Maybe I missed it, but what about methods on your context who do not transform state but are only affected by state? Would I also delegate this first to the state object or just put a condition check if I'm in the right state? Something like setName() in on a document object which is only allowed in a certain editable state?
Hi Christopher, great videos and playlist. It helps me a lot to appropriate design patterns.
About the State Pattern, it kinda looks like the Strategy Pattern as each state has its own logic, right? I would define the State Pattern as an evoled Strategy Pattern. Do you agree? Do you consider make a new video in this playlist to explain the difference(s) between these two?
Thanks again :)
Hi Christopher, first thanks for making this series. I actually have questions regarding state pattern around 1:11:15. I see that whenever you change state you initiated a new state. I think for the same gate, if it opens, closes, and repeat, it should reuse the existing state. Am I wrong? I don’t understand the potential benefit of countinuous instantiation. Any light shed on my confusion would be appreciated.
Great video! I have been struggling to understand State Pattern but you made it really clear!
I’m not very sure but the sample code you provided seems to be impossible to instantiate (apologies if I’m wrong)
The reason is that the Gate class requires GateState object in the constructor while GateState requires Gate object in its constructor. It looks like circular reference, would it be possible to instantiate? (I’m gonna test it out when I’m available)
Hi Christopher, I have a suggestion regarding this pattern. I think methods in State interface can be of return type State instead of void & inside gate class or the context, whenever delegating to the Concrete State Classes we assign the return State like - "this.state = this.state.payOk();" and (return this) or create the required ConcreteState Object in Concrete State methods.
and this adds only one assignment in every method of context.
BTW Awesome Videos, Best Videos on OOP & design patterns on Internet, & lots of Thanks from India.
He actually mentioned this type of implementing the pattern at 49:30 in the video. It sounds like a neat concept at first but if we were to use the design example from the headfirst on using a gumball machine, the dispense method should be handled by the gumball machine and not the states. So it wouldn't be easy to call Dispense from TurnCrank because we have no reference to the base class. Also the base class may need to set its own state as well.
Chase Payne
Sorry My bad, maybe I unconsciously get this idea from this video. Thanks it's there, He is the best.
Should not the handle method of each State returns the next State or itself? Does not each call to handle makes a state transition?