Most Read This Week
By: Hal Helms
Jun. 16, 2003 12:00 AM
It is not enough to do your best; you must know what to do, and then
do your best."
In several recent CFDJ articles, I've described software architecture as akin to model building. In both designing software models and building scale models, it's important that the model be internally consistent as well as sufficiently rich to encompass the desired behaviors of the real-world system.
For example, if you want to create a model car, you will want to ensure that it's internally consistent (turning the wheels does not cause the hood to open, for example) and rich enough so that if, for another example, we open the hood of the car, we see a model engine.
Software, of course, isn't nearly so visual as a scale model - a fact that makes the discipline of software architecture difficult: when you set about building a software version of a model car, all the construction occurs in your mind. The problem is that brains aren't particularly good at storing large amounts of complex information, so our species has developed writing and drawing as ways of documenting our thoughts. Software architects employ a variety of tools to translate the invisible to the visible - from cocktail napkins to UML diagramming programs.
But static scale models themselves are not capable of doing the real work needed to provide benefit to users. A superficial object model analysis may determine that we need (for example) both a Car and an Engine object, but this alone doesn't specify how the two will work together.
Identifying objects isn't enough; we must make sure that those objects interact properly. And that's precisely the definition of a system: a group of interacting, interrelated, or interdependent elements forming a complex whole.
In my simple example of a Car and an Engine, it's simple enough to see their relationship, but the more complex an application is, the more it must do, or the more likely it is that our application will change over time, the more important it is that we build a system that is flexible enough to withstand the shocks of future changes - that we have thought through the best ways for our objects to interact.
Too often though, a software application is seen as a solution to a specific problem. We (hopefully) find out what users want and then build it for them. But this approach misses a key ingredient of virtually all software requirements - that the requirements themselves will change as the business environment changes.
In more stable times, software could be built and counted on to run without alteration for years, even decades. But the pace of change has accelerated to a point where software is often out of date before it is even released (and this is a large cause for the high degree of software failure). Therefore the need for good systems analysis is greater now than ever.
But how shall we design systems for future environments, which, by their very nature, are unknown? Over many years of building software, we have found that the most successful software (in terms of longevity) has certain common features, such as information hiding, encapsulation, and loose coupling. A great deal of theoretical understanding has been gained from the study of both successful and failed software systems.
Does such theoretical knowledge help those of us in the trenches, though? It does - both in the design of modern languages such as Java and, of more immediate use, in the rise of concrete guidance on how to design flexible systems of object interactions. Such guidance is known by the term, design patterns.
Design patterns are unique in that they offer help on deciding how objects should interact - how, in essence, to create mini-systems that are maintainable. If that sounds too abstract to you, consider a design pattern in a field different from our own. (Apologies to our international readers who may not be that familiar with the American pastime, baseball.)
A Practical Example
You've got the fans, the salary, and (most profitably) the endorsements. But alas, you lack experience. There are limits, it seems, to even the most magical of wands and some things cannot be granted; they must be learned.
As you take the field, you try to recall the games you've seen on television, hoping for some guidance. You search for memories of other shortstops you've seen, trying to remember whether the shortstop stands between first and second base or second and third base. Since the second baseman is already somewhere between first and second base, you casually jog to the empty spot between second and third. When no one laughs, you breathe a sigh of relief: one hurdle passed.
You find yourself hoping that the opposing batters will hit long fly balls that will be fielded by outfielders. The first batter is up and does exactly what you were hoping - almost: on the first pitch, he hits a long fly ball - so long, in fact, that it easily clears the right field wall for a homerun.
The second batter comes up to the plate, and the pitcher, shaken by such an early homerun, walks him. With a man on base, the infield (which you're part of) becomes more attentive; the second and third basemen shift their positions. The next batter takes two strikes then pops up a very short fly ball. You watch the arc of the lazily hit ball until you realize that it's coming down very close to you. You think you can catch it, but should you then throw it to first base? To second base? Back to the pitcher?
The ball descends but before it arrives, the umpire calls: "You're out!" and the batter begins to trot out to the dugout. But you haven't caught the ball, yet! When it finally lands in your glove, the pitcher is already standing with his glove toward you, waiting for you to throw it back.
Perplexed by this - does baseball have mulligans? - you glance toward the third baseman. He smiles. "Infield fly rule," he says knowingly. You vaguely remember hearing about the infield fly rule, but there's no time to think about it, for the next batter is up and you realize with horror that it's Barry Bonds.
With the first pitch, Bonds swings and connects. It's a hard ground ball - and it's headed straight at you. The ball is moving impossibly fast and it's instinct alone that prods you to put your glove out in its general direction. Smack! The ball takes a bounce and lands in your glove.
No one is more surprised than you are. But there's no time to reflect on your good fortune; the batter on first base is running with all his might toward second base. The second baseman calls out "Two!" as he's headed for second base. Confused, you pick up the ball and weakly throw it to him. He catches it effortlessly, tags the bag, and then fires a strike to first base. It's all happened so fast that you're not sure what occurred, but your teammates are headed to the dugout and one of them pats you on the back telling you that you made a good play. You've survived your first half inning of play. Welcome to the majors.
If someone were to come up to you at that point and say that you had executed the Double Play design pattern perfectly, you might think them a bit odd. And yet, that's exactly what you did. But you've never studied baseball design patterns - how could you have known what to do? The answer to this question is key to understanding how to use design patterns.
You don't set out to use a design pattern; rather you find yourself in a situation where you must make a decision. What the design pattern does is tell you, "In this situation, the following actions have a higher degree of success than any others we have discovered." In the situation you found yourself in playing shortstop, the Double Play design pattern represented the most successful action you could take.
The Reality Behind the Name
René Magritte, commenting on the human tendency to idolize (literally) reality, painted a now-famous picture of a pipe, under which he wrote the words, Ceci n'est pas une pipe: this is not a pipe. The name of a thing is not the thing itself, the map is not the territory, and learning the names of design patterns alone cannot provide guidance on building robust software.
In fact, the names given to design patterns can sometimes make them seem far more mysterious and complex than they are. But design patterns exist only to help you, not to act as a judge on your actions. Mastery involves learning both what design patterns exist and when each is appropriate. Only then can we use what we have learned for our ultimate goal - to craft systems that provide the power and flexibility that both we and our clients want.
If you'd like to learn more about design patterns and in particular their application with ColdFusion Components (CFCs), see the series of articles by Brendan O'Hara, "Design Patterns in ColdFusion," currently running in CFDJ, which started in the March 2003 issue. www.sys-con.com/coldfusion/article.cfm?id=577.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads