So last night I put on my magical imagination cap and pretended to be a software engineer. I did in fact open that book that I haven't touched for 3 years and unfortunately it was mostly about refactoring, not so much patterns. I did however, start scavenging on wikipedia and found some very interesting things.
It seems that FSM proposal we dreamed up is a combination of 3 patterns:
1) Dependency injection
2) Service Locator Pattern
and 3).... get ready for it, its the most unintuitive name ever....
the
State Pattern
I know right? What nutball thought of that name?
Anyway, I knew the State Pattern was a thing, but what I didn't know is that algorithms encapsulated in other objects was a core feature of it. I'll go through and explain how each of these patterns applies here. To any readers, don't take what I say as a fact or anything because I am certainly not an expert, but here goes:
Dependency Injection is just a fancy way of saying that an object is given it's state variables rather than creating them. We create algorithm objects and give them the components they need to operate, and that's really all there is to it.
State Pattern is the obvious one here. The defining feature is that you write these abstract algorithms and then the using object gets assigned one service at a time that it then delegates its responsibilities to. I think this is very similar to the delegation pattern that Noxid mentioned, though if I understand correctly, delegation pattern is just sort of an umbrella term for breaking up class responsibilities. Wikipedia had some cool diagrams of the state pattern:
The
Service Locator pattern is one im not totally sure about. The pattern states that the core idea is that objects have their services (algorithms) chosen for them instead of choosing themselves. While the fsm is part of the class in question, and it declares all its needed algorithms up front, it still does not directly choose the algorithm its running, and therefore I think this still falls under this pattern description. If someone has a better alternative im all ears.
So it's good to know that the solution isn't totally out of left field and has some basis in practice. I'm still struggling with a good way to make this fit into my overall program architecture so far...
