Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Design Patterns for the People

Stephen Dewhurst pledges real-life C++ solutions rather than academic brain-candy.

By Rick Wayne
March 26, 2003

“I’m not going to give anybody headaches today,” promised Stephen Dewhurst as he began his Monday morning tutorial, “Practical Design Patterns in C++.”. The president of Semantics Consulting faced the challenge of guiding his class through a topic—design patterns—that has earned a reputation for ivory-tower treatments. But Dewhurst was determined not to lose anyone to esoterica hypoxia along the way. Instead, he offered his students a pragmatic set of concrete techniques to use in their own projects—though he cautioned them that this class won’t let them just plug-and-play. Instead, he said, “After you read and internalize these patterns, you’ll feel like you just had a conversation with an experienced colleague.”

First, though, like any patterns-oriented designer, Dewhurst had to place the problem in its context. Design patterns aren’t paradigms, he said; those are larger-scale methods of thinking. And they aren’t idioms, either—idioms are language-specific, recurring snippets that evolve over time. “A design pattern provides a solution to a common design problem within a particular context, and describes the consequences of this solution.” Dewhurst pointed out the need for a specific, precise language to illuminate design discussions. Overuse, he said, eventually erodes the precision of common terms. “It’s useless to call something a ‘wrapper’ anymore,” he complained. However, “When we use terms like ‘binary search’, we have an exact technical vocabulary for discussing these things. We may disagree [on the technical details], but at least we’ll have intelligent disagreements.”

Dewhurst was scornful of the me-too techniques that arose in the wake of the design-patterns movement: “code patterns, antipatterns and other abominations like that.” He did relent a bit for antipatterns, admitting that avoiding known pitfalls was useful (Dewhurst is, after all, the author of C++ Gotchas), but urged students to concentrate on the good solutions first, and only then winnow out any bad actors that creep into the design.

As helpful as patterns can be, Dewhurst warned, they’re not magic pixie dust. “Using design patterns will make you more productive and wittier at parties, but they don’t relieve you of responsibilities.” In fact, he claimed, the opposite is true: Users of design patterns tend to become more scrupulous about the details of a design. “So as this day goes on, your situation will get worse and worse,” he quipped. He counseled students against the programmer’s trained-in tendency to generalize, at least when applying patterns. For example, he said, it’s easy to lump the Façade, Bridge and Proxy patterns into the “wrapper” category, but such a specious handle is useless when it comes to actually producing solutions: “Focus on the differences. [Use] precise names and restricted meanings. Counter to the advice you parents gave you, I’m going to suggest you become narrow-minded.”

As he worked through the catalog of patterns, Dewhurst kept the focus on real-life solutions rather than academic brain-candy, and was careful to point out the real-life C++ pitfalls as well, paying attention to details like object destruction and multithreaded access. He succeeded in convincing the class that design patterns were applicable to real programmers’ work. “I wish I’d known about these things 15 years ago,” he laughed. “I would have been able to have a life.”

RELATED ARTICLES Q&A: Software Testing In A Virtualized World Secure Software Needs Careful Testing -- And Lots Of It Securing the Java Core Petascale Tools and Genomic Evolution Legal Compliance: Open Source and Quality Assurance		TOP 5 ARTICLES No Top Articles.