Evolutionary architecture and emergent design: language, expression and design

Introduction: The ability to discover and accumulate idiomatic patterns is critical for emergent design. It is also very important for design to be the expression of the code. In the 2nd installment of this series, Neal Ford will continue to discuss the intersection of expression and pattern, illustrating these concepts through idiomatic patterns and formal design patterns. He reconstructed some classic four-person (Gang of Four) patterns for the JVM using dynamic language to illustrate how the more expressive language allows you to see the design elements that are obscured by the opacity of the language.

This article is part 2nd of this series, designed to demonstrate the importance of computer language expression (allowing you to focus on nature, not form) for emergent design. The divergence between intent (intent) and results (result) is a common problem for many older languages (including the Java™ language), thus adding unnecessary forms to the issue-solving effort. More expressive languages can help developers find idiomatic patterns more easily because they contain less useless information. Expressiveness is a feature of modern languages such as Groovy and Scala; the older but more expressive languages include Ruby (where JRuby is a variant of the JVM), and other, more expressive languages include refurbished Clojure and modern Lisp based on the JVM. In this article, I'll go on to the demo in part 1th-using the traditional four-person group pattern in the book of design patterns in a more expressive language.

Modifier pattern

A four-person group of books defines a modifier pattern as:

Assign additional responsibilities dynamically to an object. Modifiers provide another flexible inheritance method for extending functionality.

If you have ever used a java.io.* package, you should know something about the modifier pattern. Clearly, the designers of I/O libraries read the modifiers section of the four-person book and understood its core meaning! First, I'll demonstrate the traditional implementation of the modifier pattern in Groovy, and then improve its dynamics in subsequent examples.

Traditional modifiers

Listing 1 shows a Logger class, along with some modifiers (Timestampinglogger and Upperlogger) associated with the class, that all code is implemented in Groovy:

Listing 1. Logger and two modifiers

class　Logger　{
　　def　log(String　message)　{
　　　　 println　message
　　}
}

class　TimeStampingLogger　extends　Logger　 {
　　private　Logger　logger

　　TimeStampingLogger(logger)　{
　　　 　this.logger　=　logger
　　}

　　def　log(String　message)　{
　　　 　def　now　=　Calendar.instance
　　　　logger.log("$now.time:　$message")
　　}
}

class　UpperLogger　extends　Logger　{
　　private　Logger　 logger

　　UpperLogger(logger)　{
　　　　this.logger　=　logger
　　}

　　def　log(String　message)　{
　　　　logger.log(message.toUpperCase())
　　}
}