On Mon, Sep 30, 2002 at 11:22:02PM -0400, Michael G Schwern wrote:
> Last year at JAOO I stumbled on this thing called Subject-Oriented
> Programming which looked interesting.
There are a bunch of "advanced" programming techniques like this that
all fit under the same umbrella:
* Subject Oriented Programming (IBM)
* Aspect Oriented Programming (Xerox Parc)
* Composition Filters
* Adaptive Programming - Demeter Method and Propagation Patterns
They're all attempting to achieve the same goal - a clear separation of
concerns - and although the details are different, the overlying
principal is the same.
They are all metaprogramming layers which allow you to put wrappers around
your code, and in particular your objects. These wrappers intercept method
calls and can modify them, redirect them, and otherwise jiggle around with
them in all sorts of interesting ways.
For example, AOP identifies cross-cutting aspects (like error handling,
logging, etc) which cut across an entire system. It's considered bad
form to implement logging is each of the 20 object classes you're using
because you've lost the separation of concerns. If you want to change
the way logging is handled, you have to go and change 20 classes. You
can use inheritance or delegation to acheive a clear separation of
concerns, but these have their own problems. The inheritance route
tends to lead to large and cumbersome object hierarchies that are fragile
to change and beset with the problems of multiple inheritance. Delegation
is sometimes better, but tends to lead to highly fragmented programs
where it is difficult to see the wood for the trees.
AOP tackles this problem by allowing you to define different aspects
of your program (e.g. database access, user interface, error handling,
logging, etc.) and then "weave" them together by defining "join points"
and leaving the pre-processor to "join up the dots". Template processing
systems are a simple example of AOP. If you write a CGI script with
Perl code and HTML fragments interleaved then you make it hard to read,
update and understand. Better is to define your Perl code in one place
(the implementation aspect, or "model" in another parlance) and your
HTML markup in another (the presentation aspect, or "view") and then leave
it to your favourite template processor to weave the two together.
The approach of SOP is to define an object-like entity, the "subject"
which is a wrapper around one or more objects. This acts like a facade
around the inner objects, allowing method calls to the subject to be
directed to the appropriate inner object, possibly with various forms
of manipulation taking place en route.
For example, you might have an "employee" object defined by your accounts
department which includes payroll number, employee information, salary,
etc. You might want to reuse this object in another application but
without exposing salary details for employees. By defining a subject
to enclose the object, you can effectively hide these fields. You can
also create composite subjects where an "employee" has a dozen fields,
methods, etc., which are implemented by 3 different underlying object
classes. Or you might want to implement some kind of security layer in
your subject so that only certain privileged people have access to
sensitive information. You do all these things in the subject wrapper
and don't need to change your underlying objects.
Composition Filters are very similar but substitute "subject" for "filter".
You compose collections of object and define how the method calls to them
should be filtered.
Adaptive Programming is slighty different in that it defines a methodology
for modelling a problem domain, and provides tools for generating code (C++)
to implement it. The Demeter Method is a best-practice approach for
designing your underlying objects so that they fit nicely together.
Propagation patterns are used to say, in effect, "the shoulder bone is
connected to the arm bone", you turn the handle and out comes your code,
with everything connected together and working in harmony as it should be.
This is a form of Generative Programming, which is the general term for
any process whereby you define a high-level model of a program and have
generators actually write the program for you (or more commonly, just the
"wiring" code between existing objects). This is slightly different from
the usual metaprogramming approach of AOP and SOP which make extensive use
of C++ templates to pre-process your program code.
As for Perl implementations... hmmm.
The key step is to identify/implement a mechanism whereby we can
put hooks into object vtables, allowing user code to intercept methods
called against objects. Ruby has an AOP module (AspectR ISTR) which
does this, making it trivially ea
