View all newsletters
Receive our newsletter - data, insights and analysis delivered to you
  1. Technology
April 28, 1997updated 05 Sep 2016 1:07pm

PATTERNS IN SOFTWARE DESIGN – PART 1

By CBR Staff Writer

This is the first section of a two-part story. The second portion will appear in the April 29 edition of Computergram International.

Some ivory-tower advocates of patterns are too busy playing Plato. It’s time boilerplate design was thrown to the people, Lloyd Blythen believes

Weighing heavily on my conscience is a lie I once told some gullible college kids: that programming is a matter of simple principles. As the 600-odd pages of Donald Knuth’s Fundamental Algorithms attest, there’s nothing fundamental about programming at all.

If only we could distill the years of experience that truly expert programmers draw on in breaking down a task and performing it. Then, instead of a bottom-up attack – one that bewilders the student with algorithms, data structures and class-hierarchy designs before they’re able to cement their knowledge by using it – we could start by learning essential, ubiquitous techniques for software design, which we’re sure to repeat over and over, and start applying them from the outset. I don’t suggest that the minutiae are avoidable; they’re not. But as an example, instead of learning five sorting algorithms it might be beneficial if we learned to recognize ‘sort-worthy’ applications first. Most programmers use few sort routines, and without knowing more than one it’s possible to learn a lot about software design.

It’s been done, and I hasten to add that it wasn’t my idea. In fact, it wasn’t even a programmer’s idea to start with. Just as chaos theory found its way into mathematics by courtesy of an atmospherics scientist, so-called ‘patterns’ were co-opted by the software community from outside. (Patterns amount to one of the biggest applications of re-use that our industry’s ever benefited from.) For decades Christopher Alexander, an architect (the kind who talks bricks, not bytes), developed a unique scheme for planning towns and buildings. He identified dozens of time- honored, fundamental design solutions that applied across many scales and in many situations, along with the ‘Alexander form’ for describing them. His idea was that the best of skilled design should be available as a set of boilerplate abstractions.

Take, for example, the problem of negotiating a dip. One high- level pattern for solving it involves a bridge of some sort – without regard for how the bridge is best constructed in a given situation, or for whether the dip amounts to a dry gulch, a street below two neighboring skyscrapers, or a river flowing between two banks, or for whether the bridge is to be traversed by trains or pedestrians. Other patterns applicable to the same problem might involve tunnels – again, whether for people, ducks or cables is immaterial to the pattern’s usefulness.

Such patterns were most valuable for one feature: they strenuously avoided specifying implementation details, so that their applicability might be as broad as possible. Over time, Alexander indexed several hundred abstractions for solving design problems. By then he was prepared to claim that an entire building might amount to no more than the realization of a set of patterns, many of them applied repeatedly and at varying scales, and sometimes in concert. He’d identified re-usability and genericity in architecture, and set about trying to have them applied deliberately rather than haphazardly. But Alexander was ahead of his time: many in the architectural community interpreted his efforts as an attempt to stifle an art form, and for a while they spurned him as an untouchable.

Content from our partners
The growing cybersecurity threats facing retailers
Cloud-based solutions will be key to rebuilding supply chains after global stress and disruption
How to integrate security into IT operations

It took Kent Beck and Ward Cunningham to recognize that Alexander’s work held the promise of a revolution – not in architecture, but in the software engineering field. The first software design patterns arrived in the form of their recommendations for GUIs and for capturing business models in software, in the early ’90s. In 1991, a set of patterns was published as part of a now-famous doctoral thesis by Erich Gamma. Partly as a result of its being written in German, this work didn’t receive widespread attention.

Websites in our network
NEWSLETTER Sign up Tick the boxes of the newsletters you would like to receive. Tech Monitor's research, insight and analysis examines the frontiers of digital transformation to help tech leaders navigate the future. Our Changelog newsletter delivers our best work to your inbox every week.
I consent to New Statesman Media Group collecting my details provided via this form in accordance with the Privacy Policy
SUBSCRIBED
THANK YOU