This weekend I had a chance to read the paper Incremental Programming with Extensible Decisions by Doug Orleans. In it, it discusses a prototype framework that implements a variant of AOP and Predicate Dispatching.
The paper was though provoking and definitely convinced me that I need to be looking into trying to AOP or related approaches in my production work. But what I found really interesting, and what's been on my mind for the last few days is in the very first sentence of the introduction:
Incremental programming is defined by Cook and Palsberg
as the construction of new program components by
specifying how they differ from existing components
Doug goes on to explain that OOP fits the definition of incremental programming:
Object-oriented programming (OOP) languages typically support
incremental programming with inheritance and dynamic dispatch
features. Whenever a message is sent, a decision occurs, but the
branches of the decision can be specified in separate components,
I suppose this is all fairly obvious in retrospect, but I tend to think of OO as more of a packing mechanism. If I want an authentication framework I could create it procedurally by outlining various functions, and passing the state in explicitly. Such as:
$data = lookup_user($username);
if(is_authenticated($data, $some_password)) { ... }
...
If I wanted to do this in OO, I could bundle the state and functionality together. Such as:
$obj = new AuthModule($username);
if($obj->is_authenticated()) { ... }
...
Obviously, there are pros and cons to using OO or procedural approaches, and of course, at some level, they are equivalent.
Doug's comments suggest that OO can be more than organizational technique, or a helpful modeling tool. Imagine if you built a system completely by bending and shmooshing together existing components. Inheritance based OO isn't powerful alone enough to do this, but with AOP and other approaches, perhaps you could.
The goal of a programming language and frameworks, I think, is pretty simple: allow you to get a job done by writing as little code as possible. Perhaps, incremental programming is a way to do that.
It would be an interesting exercise to try to develop a fairly sophisticated application built purely incrementally. Of course, you'd need to define the ground rules of what that would mean. But once you had the rules of the game established, it would be interesting to see what came from it.