Oct 04, 2004

The Pattern-Based Future...

InformationWeek has an article about Grady Booch about the future of software, and it appears that Grady thinks that the future is in Patterns, described as “algorithms that pull together objects.”

As a recap, the Software Patterns Movement started when Design Patterns: Elements of Reusable Object-Oriented Software (affectionately referred to as the GOF book) was published in 1994, and was greatly inspired by the works of Christopher Alexander, such as in The Timeless Ways of Building where Christopher's premise is that by observing and communicating architectural patterns, buildings could be made to perfection by simply assembling compatible patterns. Interestingly enough in Christopher's book, he states that all patterns should be written down, and in another round of the survival of the fittest, only the most fit patterns will spread.

In the software world, when the GOF book was published, an entire myriad of software patterns books were published. These software patterns vary in quality, but there are a lot of design patterns. It has become so uncomfortable to track down software patterns that books like The Pattern Almanac 2000, not to fail to mention a few attempts at publishing such information on-line, help organize them.

The article that started out this entire babbling kind of makes it seem like software patterns are new, but they are not as I have highlighted above. This being said, I still think that software patterns are important and are very much a part of the future. There is a lot to be learned from software patterns. As just a simple example of this, I have recently discussed the scope of class data members as being something fairly new to place data members as private instead of protected, however, if you look at the source within the Design Patterns: Elements of Reusable Object-Oriented Software book, many examples use this technique.

Learning algorithms and patterns is a way to leverage knowledge from before. There are very few problems that we solve that, as much as we would hate to admit, are truly unique. Generally the way that we build software today is by building components and modules and they are combined in ways that make our global application more or less unique, but many of the components created and the interaction between the components are not unique. Software patterns, like algorithms, present us with a catalog, where we can browse through the catalog in order to select patterns that meet the criteria that we are attempting to obtain from the software. In addition to this, it provides a language to communicate with other engineers; without the QuickSort algorithm, how would you describe the QuickSort algorithm? Just the QuickSort name provides a mental pictures in engineers that you do not need to describe the internal workings, such as the partitioning mechanisms, in detail.

Patterns offer the same communication advantage, however, the GOF book has introduced a form that patterns are in that can make patterns better. When dealing with books on algorithms, the algorithms generally only present the algorithm and may describe some areas where the algorithm will perform well and where it will not perform, but the form that algorithms are presented varies greatly from book to book. With software patterns, the GOF book has proposed a form that most software design pattern book follow. This form allows you to quickly look at the description and know what it does, why you may want to use it, how it works, and some consequences of using the pattern. This description provides you sufficient information to decide whether the pattern is applicable to what you are trying to do.

As Christopher Alexander mentions in The Timeless Way of Building, some patterns will eventually become part of your language, whereas others will not. Part of this is applicability, but part of this is also exposure, as Christopher mentions that the initial subset of a language that child learns is based on the set of words that the child is exposed to. As the person is exposed to more and more vocabulary, the person can make the vocabulary part of their language, or the person will simply know what the word means. And this becomes the language that you hear when communicating with them, similar to the words that I use on this blog are in the subset of my language.

The movement from algorithms to design patterns is a natural progression, as I mentioned in Knowing The Language. When we used to develop code line-by-line, it was easier for us to think at the algorithms level, however, with objects and components, it becomes more important to think at a higher level, and to describe the interaction of objects and components. This is where design patterns are incredibly useful, and I agree with Grady that this is not going to change in the immediate future.

Filed In