Design patterns, or why Java needs external crutches

In my last blog about architecture and design I promised to come back on the topic of design patterns. This term was coined in a famous book that proposed a catalogue of "Elements of Reusable Object-Oriented Software", and became a best-seller in the Java world (usually referred to as the "GoF" book, for "Gang of Four" authors). Feeling the golden ore, all editors quickly produced a whole line of similar books, where patterns were adapted to various domains and languages : for C##, for Ruby, ..., etc. I almost expected to see patterns books for assembly code and for Befunge, but these never came out !

So what about patterns for Perl ? To my knowledge, no major editor published any book on that topic, which is kind of surprising because one would think that there is some money to make. However, Phil Crow privately published Perlish patterns (cheeply available as e-book), which is really worth reading; Phil proposes the following explanation in his introduction :

Eventually, I came to understand that there were several reasons why patterns were never as enthusiastically embraced in our community as they were in others. Some of the patterns just apply new names to common techniques. Some are represented in Perl's core, so we don't think much about using them, at least in their normal forms. Some apply better to languages which focus on object orientation.

I very much agree with this analysis. The original GoF book was refreshing to read, but when programming in Perl I never think in terms of those patterns, because the standard language features plus some common CPAN modules answer most of my needs for structuring my programs, even when assembling large bodies of functionality.

The fact that Java is so verbose, and that everything has to be an object, results in code that is often spread among lots and lots of classes. So to condense that information, it is no surprise that Java programmers need other abstractions like "patterns", so that they can think in terms of larger units. For the same reason, they also need sophisticated tools like Eclipse for navigating through the class hierarchy, and they need costly tools like Rational Rose to see and design the big picture, and generate code skeletons. I'm always surprised to hear such tools presented as strenghts of the Java world, while to me they are just necessary consequences of the way Java code is layed out.

In standard Perl, we have hashrefs and arrayrefs, we have closures, multiple inheritance, namespace manipulation primitives, dynamic classes and dynamic methods, functional grep, map and other List::MoreUtils goodness; we can assemble those into dispatch tables, delegation structures, function and method templates and factories ... enough patterns to fill a whole life !