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.
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.