Hacker News new | ask | show | jobs
by froderick 3117 days ago
The tricky thing with abstract class (oop) hierarchies is that deeply nested ones tend to be 1. hard to understand because parent behavior is shared concretely rather than modeling it behind protocols. 2. hard to change without breaking lots of dependent code because the dependencies are not obvious. 3. hard to debug because state internals easily leak out of parents and into children.

I wonder how they're managing this problem in HSM's. Seems like transitions between parent/child states would need some kind of protocol to define state entry/termination criteria so that the concrete dispatch mechanisms themselves could be abstracted away from the parents/children.

Maybe its just me.

1 comments

I recently started a job where I was introduced to HSM's. The answer is, there isn't one. The resulting C reads like the entire program was written in main() and connected via glorified gotos. Every module depends on a global event queue, and event data is passed via circular dependency on effectively global state. I have never seen such basic logic so obfuscated and so distributed.

It might just be this codebase, but I do not see the appeal to HSM's. I'll stick with my standard flow control (while, for, break, return) and compose functions from other functions. It sure is nice to make calls that actually return.