Patterns in Practice
Over the past several months MSDN Magazine has welcomed a pair of new columns—Rachel Appel’s Modern Apps and Bruno Terkaly’s and Ricardo Villalobos’ Azure Insider. We’ve also seen Charles Petzold rebrand his column as DirectX Factor, reflecting his shift to exploring the DirectX infrastructure of the Windows Runtime. What you may not know is that we’ve also been busy on the Web site. In January we introduced a new monthly online column called Patterns in Practice, written by veteran MSDN Magazine author Peter Vogel.
As the name of the column suggests, Patterns in Practice explores the value and potential of design patterns by applying them in working scenarios. In his inaugural column, “Adding Functionality to an Object” (msdn.microsoft.com/magazine/jj890759), Vogel looks at an application managing sales orders, and how the client can dynamically add permitted functionality to an object as it’s needed. Vogel explains that his columns will present a business problem and discuss a few alternative solutions before diving into, as he writes, “a solution that addresses the problem in a testable/maintainable way, based on some design pattern.” From there, readers can expect to follow along as Vogel builds out the design and implements the solution.
I asked Vogel why he wanted to focus specifically on design patterns. His response:
“I keep working with programmers who are trying to address the ‘-ities’ that design patterns address: reusability, maintainability, extensibility, testability. But these developers don’t look to the already existing solutions that design patterns provide, because they don’t see design patterns as sources of useful inspiration or direction. They see patterns as being more like straightjackets: some guy yelling at you that ‘You’re doing it wrong!’ This is compounded by many of the design pattern examples being about things that most business application developers would never build—editors, for instance.
“I want to show that design patterns should be as much a part of a developer’s toolkit as relational database design or structured programming. Design patterns are, to me, all about moving from ‘thinking in procedural code’ to ‘thinking in objects.’ This column should demonstrate that design patterns, like the three levels of data normalization, provide very helpful answers to some very common problems.”
The fruits of this effort are already visible in the energetic back-and-forth in the comments section of the first Patterns in Practice column, and are shaping the direction of Vogel’s coverage today. Vogel says he adjusted the design of his object model—presented in detail in his February column, “Data Design for Adding Functionality to a Class” (msdn.microsoft.com/magazine/jj984634)—based on compelling arguments made in response to the first Patterns in Practice column.
“While I’m always resistant when people disagree with me, I do try to generate questions that will resolve the discussion one way or another,” Vogel says. “That lets me go out and look for the answers to those questions and apply the evidence instead of just stomping my feet or falling back on ‘principles.’”
Vogel says he sees several common mistakes when it comes to working with patterns, starting with developers who fail to take advantage of patterns where they would be truly useful. “Developers end up spending time reinventing the wheel and ending up with an oval when a circle would have been a much better choice,” he says.
Vogel continues by noting that modern toolsets make common patterns easy to implement, yet many developers aren’t aware of the available resources. Finally, he says, developers can run into the problem of misdiagnosis—they either misunderstand what a design pattern is intended to address or misdiagnose the problem they’re trying to solve.
In the months to come, you can expect Vogel’s Patterns in Practice column to explore the observer pattern and how a variation of it is implemented in SignalR for Web-based and service-oriented architecture (SOA) applications. Vogel says the columns will show how changing technology sets can make some patterns more attractive in an environment where the pattern would, as he says, “otherwise be discarded as un-implementable.” Also look for a case study built around the decorate pattern.
Do you have a concept or pattern you’d like to see Vogel explore in his column? Write me at firstname.lastname@example.org and let us know!
Michael Desmond is the Editor-in-Chief of MSDN Magazine.