Chain Of Responsibility Engine

Or, CORE. If software tends to grow into a BigBallOfMud when not sufficiently planned and refactored, is there a way of organizing software which takes advantage of this entropy and thrives on it. Is there a way to build software which works without refactoring and without having developers maintain an elaborate picture of the model in their heads?

In the book by Cook and Daniels, they mention that reality is event based rather than object oriented (I've since heard someone say that transactions are a better model, but I have not had a chance to look at it). We can do OOA, but some notions like association can miss the mark. Well, what does it mean to be event-based? As I understand it, it could mean that events can originate from anywhere and be handled by anyone. Sunlight shines through a window and simultaneously causes plants to photosynthesize and couches to get warm. This is kind of like a broadcast model.

So, is it possible to organize software in a linear manner, over time, where new software is always added at the end and none is every deleted. Events are generated from the outside world. When a new event is presented at an interface, it is passed backwards until it finds a handler. The handler may generate new events (which start at the top again) to do additional work and then pass its results back to the interface.

The advantage is that the software can just grow. Developers can generate an event and see if it is handled. If not, they can add new software to handle it. Performance can be tuned by adding new software that does the same thing as some software already in the CORE, but by virtue of the fact that it is added later, its response will be faster. Sort of a blind delegation model or linear blackboard.

Disadvantages. Probably slow as hell, but some clever hashing might help. Would require typed messages. If message sends are decoupled from any classified target, this degenerates into a non-OO system. The lack of structuring and introspection may be prohibitive.

I recognize that this vision is extremely flawed. But hare-brained notions like this are more interesting to me in where they fail or are equivalent to something else. I find that I learn a lot in these "what-if" scenarios. What if you took OO and broke this one little piece? Feel free to ignore all but the first three paragraphs. Is there something to the intuition?

-- MichaelFeathers

This is reminiscent of PlayGround, the next AlanKay programming language for children. See OOPSLA 89 for a description. We developed a programming style that almost entirely avoided sequential control flow. It was based, as you say, on events that could be handled or not.

The weakness of the model is that it doesn't concisely communicate our intention much of the time. Some computation is most directly expressed as sequences of instructions. Some needs the flexibility you identify. -- KentBeck

This is also reminiscent of AspectOrientedProgramming, e.g. AspectJ.

RE: "Developers can generate an event and see if it is handled. If not, they can add new software to handle it."

Actually, this is a fairly common Smalltalk programming model: Unrecognized methods cause a breakpoint window to come up. You write the missing method and then tell the debug window to retry the message. The new method processes it, and you're on the road again!

Much of the rest of the idea sounds a lot like the execution of a rule-based expert system: There are lots of independent rules. New rules can be added at any time. When "inputs happen," the system chooses appropriate rule(s) according to some selection criteria and fires them. -- JeffGrigg

The rules engine may be a useful analogy here. The dark side to rules-based systems is that very quickly the humans no longer know what the system does. Because the rules kind of fire in parallel, human reasoning quickly gets swamped.

The only thing worse may be neural nets. There's literally no way of knowing what they're up to.

A good analogy to CORE might be pipes in Unix. There are all these neat things you can do by piping the output from one "atomic" operator to another. Dataflow engines similarly. -- RonJeffries

My experience has been that rule-based expert systems are weak at "else" clauses, or the "otherwise" of a set of cases; the "what to do if everything else fails" kind of idea. It's easy to say "if X do Y," but not "if none of the above, then do this." So you're often forced to either get involved in meta-level control constructs, like prioritizing the rules. Or you have to encode "not" conditions that tie the "default" rule to the details of all the other rules, causing maintenance problems. Thus more conventional techniques usually produce superior results for common business problems.

This shouldn't be a surprising conclusion because we've designed our business processes, for hundreds of years, based on a procedural paradigm. A rule-based approach is probably appropriate in some cases, but I'd expect it to be more successful in handing the unexpected or exceptional kinds of actions, rather than the routine day-to-day stuff that people have been doing for years. (They're called rule-based expert systems, not "rule-based menial ordinary day-to-day kinda' stuff" systems. ;-) -- JeffGrigg

The QNX OS' proprietary GUI system Photon handles events a bit like this. Say you have a mouse click; it is sent backwards through the stack of windows looking for something to handle it. Draw events propagate forwards so that windows on top can filter or modify the commands. This is surprisingly fast and lightweight; they use it in embedded devices! It's been a few years since I used it, so I'm not sure what Photon has been up to lately.

One of the cool aspects of this is that the message queues handling the windows do not have to be in the same thread, process, or even on the same machine (though in the latter case I think there was some sort of local proxy). This scheme can manage remote windowing or splitting display to multiple monitors quite naturally without needing a special case. (It also works because QNX messaging and task switching was blisteringly fast). Contrast this with the MS Windows approach where message dispatch happens from, usually, a single point in the code with a message cracker that has to work hard to get the activity out of its own thread.

See:MetaModel