Jazoon ’09: Patterns in dynamic languages
Speaker: Neil Ford, Thought Works
Warning: This entry assumes knowledge of GOF patterns…
Observation on the GOF (Design Patterns) legacy: Many of the patterns were really good at getting over C++ nightmares.
Boy does the blogger agree with the following statement: UML is too technical for non-techies; not technical enough for techies.
Iterator: Super-easy in Groovy using closures; requires a non-trivial interplay of interfaces and classes using the traditional GOF pattern. Lesson: What’s commonly needed will eventually be subsumed by language features.
Command pattern: Modern languages implement this using closures. Java, for example, again requires a command interface, command implementations etc. Structure (e.g. adding undo/redo) can be easily added on an as needed basis.
Strategy pattern: Using code blocks in Groovy instead of adding extra classes, as one would in Java.
(Must see article: Execute in the Kingdom of Nouns from Steve Yegge)
Template Method pattern: Traditionally declared using abstract methods in classes. In Groovy we can use variables that hold onto code blocks, thus eliminating the need for the abstract methods. Use Groovy’s null dereference operator to avoid null pointer exceptions when the code blocks are null.
Interpreter pattern: Originally designed to overcome deficiency in language being used by creating a new language on top of the current language. Alternative: Groovy permits us to easily create new DSL using the “expando property” feature. Ford notes the fact that a new form of pattern is arising: Patterns of DSLs (Ford notes that Martin Fowler is going to release a book on this very subject in the coming months.) Ford notes that internal DSL’s amount to embedding an interpreter.
Decorator pattern: Groovy’s invokeMethod feature can be used to achieve what requires Aspects in Java. Inline decoration is also possible. Ford goes on to explain a few other interesting aspects of Decorator… but I can’t keep up ‘cos I’m not familiar enough with Ruby!
Adapter pattern: In Java we need to wrap existing entities to achieve interface compatibility. Ford shows a really interesting Ruby-based approach which involves dynamically changing the interfacing of an object at runtime. Notes that this can only be done with interpreted languages and that similar things can be achieved using AST transformations in Groovy. However, the latter is more difficult than in Ruby because of it’s nature as a truly interpreted language.
Null object pattern: In Groovy null dereference operator can be used to handle the null object situation frequently. In Ruby this doesn’t work because even null (nil in Ruby) is also an object.
Aridifier pattern: Avoid repetition. Ruby example shows how test methods can be created on the fly to reduce code footprint significantly.
Ford’s Summary: Traditional DPs use a lot of structure to solve problems. Dynamic languages permit far more elegant solutions.
I’m reminded of statements made long ago (in an online article, I recall) by OO grand master Bertrand Meyer to the effect that:Patterns? All well and good but there are no replacement for language features and reusable libraries.
Ford’s presentation was absolutely first class in terms of both content and delivery.
