[troels]

When dealing with business processes, I feel that the evented nature of a formal fsm can be a bit off-putting. I have on several occasions used a batch-processing approach, that maintains state in a persistent record, giving many of the same characteristics as an fsm. Let's say we have our movie from the example (pseudo-code, obviously):

    class MovieState < Model
      belongs_to :movie
    end

    class InitialStep
      def select
        MovieState.where(state: 'initial')
      end

      def process(movie_state)
        movie_state.state = 'in_production'
      end
    end

    class InProductionStep
      def select
        MovieState.where(state: 'in_production')
      end

      def process(movie_state)
        if movie_state.movie.finished_shooting?
          movie_state.state = 'in_theaters'
        end
      end
    end

    class MovieWorkflow
      def initialize
        @steps = []
        @steps << InitialStep.new
        @steps << InProductionStep.new
      end

      def run
        @steps.each do |step|
          step.select.each do |state|
            step.process(state)
            state.save
          end
        end
      end
    end

This makes it very clear when things are happening. It's also easy to debug and test.

Of course, there are a lot of limitations, most notably that it can't deal with an async event happening. In my experience though, this can be dealt with by storing the payload of that event somewhere in the db, where the step-selector can access it on next run. One thing this model deals very well with, is delays, which is often part of business processes.

Any thoughts? Does this design have a more formal name?

[rebootthesystem]

That's the problem with kids these days. Everything has to be a friggin class.

You know we did some pretty amazing things with computers before OO. We even landed people on the Moon.

Can anyone program without OO any more?

Just saying.

[troels]

I recognise that your tongue and cheek may be in close proximity here, but care to elaborate?

[rebootthesystem]

It's just a silly observation. I come from a generation that had to create products like AutoCAD to run on CP/M systems with 64K of RAM and precious little permanent storage. As an aside, few people know that software like AutoCAD started on such --by today's standards-- crippled systems.

Anyone who came up in software development through that path has a full understanding of the cost of every bit of code written, every abstraction.

Today's programmers, unless they've taken university courses to expose them to the low level stuff, are extremely isolated from the innards of what they write. They reach for classes and objects by default and seem incapable of thinking outside of these boxes. All of this adds overhead and bloat, something you had to be keenly aware of with limited memory and horsepower.

I do understand that a higher level of abstraction in the context of massive amounts of memory and horsepower can be nice. What gets me is that this is often an unnecessary default.

Going back to state machines. One does not to create a bunch of classes and methods to implement them. I see that almost as a violation of the conceptual simplicity of state machines.

I mean, to go in a different direction, I use state machine in FPGA's all the time. The synthesized hardware works fine and represents the bare minimum necessary to implement these very high speed state machines. No classes involved. One can do the same in software development.

[dwarman]

Even earlier: I implemented a Statistical Multiplexor - 8 async serial users muxed over a single 9600 Bd synchronous line - on a Z-80 with 4K RAM and 4K ROM. In 1977. Garunteed correct data delivery over lines as noisy as 1x10^3 BERT. A datacomms protocol that can do that is not a trivial beastie. The only technique that let me fit it in was state machine. It was the start of a very successful product line. I live by FSMs ever since. Software and FPGAs. And I agree about the OO cruft. I just use a function for each state and execute to completion. Perfect for event driven systems, which datacomms are a prime example. And very lightweight. In High level world, this needs a language with functions as first class objects. I have other useful representtions too. My favorite table based form is very handily implemented in Lua, should anyone be interested in seeing it.

[troels]

Well.

I'll call it idiomatic form to use OO style in Ruby, which the article (and my examples) were written in. Considering the interpreted and managed-memory model of the language runtime, it is utterly pointless to worry about a few object instances. Heck, this is a language where primitives are objects.

I suspect we work in quite different areas though, which probably gives us very different perspectives of what matters. The kind of applications I build on a daily basis, deal with business processes, and integration with external systems. I/O is going to be 90% of my machines load, if it's ever doing any real work in the first place. Most of the time it'll just sit waiting for a human to do something though.

[rebootthesystem]

Well, of course, "When in Rome do as the Romans".

Not saying OO has no place. Of course not. That would be crazy.

[bushin]

Looks like an event loop.