I'm a software developer based in Newcastle Upon Tyne, England. I've got a wide range of experience in companies of varying sizes and cultures, and in roles of varying degrees of responsibility.
Good question! :-) It all comes down to how you decide to model your states really, but I imagine that you'd end up with the same thing. If "CLOSED" is a state and "UNLOCKED / LOCKED" are sub-states of "CLOSED", then essentially "CLOSED + LOCKED" and "CLOSED + UNLOCKED" both become composite states themselves, which kind of puts you back where we started with three states (since "CLOSED" must be either locked or unlocked).
yes, thanks i guess that in this situation "LOCKED" is a shortcut for "CLOSED & LOCKED"
What i was thinking out loud with that question was about the intricacy of composite states as you call them and if any guidance is known to deal with them, theorytically and codewise :)
Not to push you to have an answer, just if there's some reflections on how to process : setting a hierarchy of states, linking them, etc
Some methods to approach it smartly like you did :)
i assumed that enters the realm of FSM but correct me if i'm wrong ;)
I'm a software developer based in Newcastle Upon Tyne, England. I've got a wide range of experience in companies of varying sizes and cultures, and in roles of varying degrees of responsibility.
Now that you mention it, perhaps my example is actually just too simple to address your question properly - my apologies, let's have a look at this in a little more depth. :)
In the third part of this series (which I realise you've already read), I talk about parallel state machines. That hinted at hierarchy but didn't explicitly discuss it, perhaps I should extend that post to include a better example. But did you notice how in that post, we moved from the concept of a door as a container, to a room instead, which contained a door and an alarm? This is showing a hierarchy like the one you're asking about (although again in a more simple manner really). Extrapolate this to to be say, a house that has multiple rooms each with their own doors, and you have parallelism and hierarchy being dealt with at the same time, but where each room is independent of one another, whilst the whole system is still only able to be in one state (made up of the combination of the states of all the rooms) at any given point.
In terms of implementing these in code, my take on this so far with React has been that each container is itself a representation of a finite state machine. The outermost App being the entire thing, and every container below that being an FSM that either has "sub" FSMs or parallel FSMs. If you match that to the diagram in part 3, which shows the room, then the room is a container in React that contains both the door and the alarm. Diagram and code for reference. :)
The key thing to think about here is that even just by asking the question, you're thinking about planning the architecture of your application at the right time - i.e. before you've started writing it! :) Changing your mind on how a system is put together is a lot easier when it's still just a diagram isn't it. :D
I agree : thinking in terms of FSM it 's an approach that's not only easier but more related to reality of systems, if i could say so.
From your answer i understand that, in fine, a FSM can also be looked as a group of states which implies that the "root" state are defined by the states of its "children" without having to care -i assume- about all the possible states of the entire application.
I'm a software developer based in Newcastle Upon Tyne, England. I've got a wide range of experience in companies of varying sizes and cultures, and in roles of varying degrees of responsibility.
And yes, that's exactly it. Basically this whole thought process isn't really about building applications with FSMs, it's about recognising that your system is an FSM already (even before you've built it!) and using that realisation to allow you to better plan out your application from the start.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Can the "LOCKED" be considered a "sub" state of "CLOSED" ?
like
Good question! :-) It all comes down to how you decide to model your states really, but I imagine that you'd end up with the same thing. If "CLOSED" is a state and "UNLOCKED / LOCKED" are sub-states of "CLOSED", then essentially "CLOSED + LOCKED" and "CLOSED + UNLOCKED" both become composite states themselves, which kind of puts you back where we started with three states (since "CLOSED" must be either locked or unlocked).
Do you see what I mean? :-)
yes, thanks i guess that in this situation "LOCKED" is a shortcut for "CLOSED & LOCKED"
What i was thinking out loud with that question was about the intricacy of composite states as you call them and if any guidance is known to deal with them, theorytically and codewise :)
Not to push you to have an answer, just if there's some reflections on how to process : setting a hierarchy of states, linking them, etc
Some methods to approach it smartly like you did :)
i assumed that enters the realm of FSM but correct me if i'm wrong ;)
Now that you mention it, perhaps my example is actually just too simple to address your question properly - my apologies, let's have a look at this in a little more depth. :)
In the third part of this series (which I realise you've already read), I talk about parallel state machines. That hinted at hierarchy but didn't explicitly discuss it, perhaps I should extend that post to include a better example. But did you notice how in that post, we moved from the concept of a
door
as a container, to aroom
instead, which contained adoor
and analarm
? This is showing a hierarchy like the one you're asking about (although again in a more simple manner really). Extrapolate this to to be say, ahouse
that has multiplerooms
each with their owndoors
, and you have parallelism and hierarchy being dealt with at the same time, but where each room is independent of one another, whilst the whole system is still only able to be in one state (made up of the combination of the states of all therooms
) at any given point.In terms of implementing these in code, my take on this so far with React has been that each
container
is itself a representation of a finite state machine. The outermostApp
being the entire thing, and every container below that being an FSM that either has "sub" FSMs or parallel FSMs. If you match that to the diagram in part 3, which shows theroom
, then theroom
is a container in React that contains both thedoor
and thealarm
. Diagram and code for reference. :)The key thing to think about here is that even just by asking the question, you're thinking about planning the architecture of your application at the right time - i.e. before you've started writing it! :) Changing your mind on how a system is put together is a lot easier when it's still just a diagram isn't it. :D
I agree : thinking in terms of FSM it 's an approach that's not only easier but more related to reality of systems, if i could say so.
From your answer i understand that, in fine, a FSM can also be looked as a group of states which implies that the "root" state are defined by the states of its "children" without having to care -i assume- about all the possible states of the entire application.
thank you for these articles and answers :)
You're welcome, thank you for reading them! :-)
And yes, that's exactly it. Basically this whole thought process isn't really about building applications with FSMs, it's about recognising that your system is an FSM already (even before you've built it!) and using that realisation to allow you to better plan out your application from the start.