Language Support for Design Patterns in Object Oriented Agile Languages [www.usenix.org]

Gustaf Neumann (also member of the OpenACS team) and Uwe Zdun present some fascinating ideas, which get to the heart of what has been troubling me for some months now. The driving force behind this paper, in a few nutshells, is:

"[Agile] languages provide features like dynamic extensibility and dynamic typing with automatic conversion that make them well suited for rapid application development.

and:

"Large applications typically entail complex program structures. Object-orientation offers the means to solve some of the problems caused by this complexity, but focuses only on entities up to the size of a single class. The object-oriented design community proposes design patterns as a solution for complex interactions that are poorly supported by current object-oriented programming languages.

and yet (generalising for all scripting languages):

Since [agile languages are] designed for glueing components together, [they are] equipped with appropriate functionalities, such as dynamic typing, dynamic extensibility and read/write introspection. Many object-oriented [Agile languages and extensions] do not support well these abilities in their language constructs. They integrate foreign concepts and syntactic elements (mostly adopted from C++). Even less appropriate is the encouraged programming style in structured blocks and the corresponding rigid class concept, which sees classes as write-once, unchangeable templates for their instances. This concept is not compatible with the highly dynamic properties of the underlying scripting language.

Taking Perl, which I do a lot of OO development with, I can agree completely. Perl gives you these amazing flexibilities with which to block together your requirements in double time. When you start to want to develop larger systems you turn to your abstraction of choice - mine is OO (for you it may be functional programming or somethig else).

Once you have signed on to the OO bandwagon, you get design patterns and all sorts of mental tools to help you, but you start to find that your flexible "agile" language of choice starts to become, well, less agile.

Allow me an example. On a large telco project, we wanted to introduce heavy-weight error handling, to allow full error detail to be passed around to logs, web front ends, SNMP traps, tyou name it. One of my (blog-less) colleagues, Ryan, came up with a good system that used source filters to take care of clearing the error stack so you didn't have to remmember to. Source filters are a great example of a flexibility that an Agile language can offer you, but they are a sledge hammer ill-suited to OO code. For example, how about automatically bubbling the error up from one method call to the next. We didn't want to use exceptions, because we wanted to be able to raise non-fatal errors that would not alter the flow of execution. We resorted to requiring the developer to remember to surface any errors that might have been generated by a method call, but this is error prone and nigh-impossible to test for.

What we really wanted in this case, was a way to hook into the inputs and output of every method call. I discovered that apparently people have thought of this before ;) and called it Aspect Computing. This turned out to be devilishly difficult to implement in OO Perl (and frustratingly it is apparently possible in Windows COM development).

It is exactly this filtering example that Uwe and Zdun describes in the whitepaper.

My example may not have made any sense to you - it is perhaps too specific. To make sure I haven't put you off reading the paper, allow me to paste in the paper's conclusion:

The intention of this paper is to show that object-oriented scripting languages and the management of complexity are not contradictory and that it is possible to handle complexity with a different set of advantages and tradeoffs than in ``systems programming languages''. Scripting is based upon several principles of programming, like using dynamic typing, flexible glueing of preexisting components, using component frameworks etc., that can lead towards a higher productivity and software reuse. We have introduced a new language construct, the filter, that offers a powerful means for the management of complex systems in a dynamic and introspective fashion. It would have been substantially more difficult to implement dynamic and introspective filters in a systems programming language. We believe that both scripting and object-orientation offer extremely useful concepts for a certain set of applications and that our approach is a useful and natural way to combine them properly.

But please do youself a favour and go read it yourself: Filters as a Language Support for Design Patterns in Object-Oriented Scripting Languages.