Design Patterns: software enginnering is a craftmanship at dawn of rationalization
There’s a saying: “Computer scientists think they have discovered the world” (anonymous). It made me laughed at first (computer scientists are likely to be really smart guys), but I’ve started to accept the idea that it may be true. As far as I’m concerned, I believe we’re still in the early ages of software engineering – a craftmanship relying on people (like Art) rather than processes (like manufacturing). Today’s state of advancement in software engineering could be compared to what aviation was in the early 1920s: back then, planes worked well. Indeed, one could fly a plane over oceans; but it was for sure rather expensive (although everyday more affordable), far from perfect and risks weren’t really calculated. Design Patterns are just a beginning in the rationalization process of software development methods.
Year in, year out, computer scientists have been reproducing features that have always existed in traditional, more mature industries. Design Patterns have been in automotive, production engineering and construction books for decades, and only emerged in software engineering in the midst-1990s, when a group of academics known as the “Gang of 4″ (Gamma, Helm, Johnson, Disvlisses) published a book that stands on every good programmer’s shelves as a Bible.
Oddly enough, design patterns both describe problems and their solutions. The actual solution can however be used a hundred times without having 2 implementations looking even close to similar. Design patterns are no method, their use provides a framework and a common language amongst software development teams, and allow for decreases in complexity when properly applied. To state things clearly, design patterns are the ‘big picture’ components of software architecture.
Today, there are at least 23 sorts of identified design patterns, classified in 3 categories: creational, structural, behavioral. In the latter category, let’s take the example of the design pattern named ‘Strategy’. In the ‘Strategy’ pattern, one single same object behaves differently under certain circumstances and situations. For instance, say you’re home (you’re the object) planning to go to the supermarket; you’ll behave differently knowing that it rains outside or that the sun shines. In the first case, you might probably grab an umbrella, and in the latter, you will put on your most stylish sunglasses. And since objects are precisely aimed at reproducing real life situations and models, there’s one pattern for basically any situation of everyday of life.
For those who feel like going further into the understanding of Design Patterns:
- “Survey of Common Design Patterns“, a useful recap
- A free .pdf book named “Design Patterns, a Java companion” by James W. Cooper
LikeRelated posts:
.NET (C#), Books, Business Process Management, Economics, Education, Google, HP, IBM, Java, Microsoft, Organization, Project Management, Silicon Valley, Software, USA, innovation, open-source, operations
