Introducing Patterns

---

Here’s one thing to keep in mind when you’re thinking about architecture: You are not the first person to be designing this sort of application. Oh, sure, the sum total of all your work will likely be something new and wonderful. However, the individual problems and subsystems will no doubt resemble those of other applications. There are only so many ways to set up an event with multiple listeners, for example.

In the computer world, these similarities are called patterns. The term is borrowed from Christopher Alexander’s seminal work in architecture A Pattern Language: Towns, Buildings, Construction (Oxford University Press, 1977), though truthfully, there’s not all that much similarity between architecture patterns and software patterns. Patterns are a specific type of best practices. In fact, it might have been simpler to call them architectural best practices. Still, the term is common now and we’re stuck with it. While a small project may not need to make use of the knowledge stored in patterns, you should have at least a general overview of the field.

RULE

In software it’s often more important to know where to go to find things than it is to memorize them.

The Gang of Four

In the software world, patterns start with the Gang of Four. That’s the common nickname for Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, who in 1995 published Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995). The Gang of Four (sometimes you’ll see this abbreviated as GOF), brought Alexander’s concept to computing, identifying 23 patterns that applied to many object-oriented software systems.

The GOF patterns are things like “Chain of Responsibility.” The description of the pattern starts with its intent (in this case, to avoid coupling the sender of a request to its receiver by giving multiple objects a chance to handle the request). The authors then go on to give some motivation for the pattern (context-sensitive help is a good example when you want to fall back on increasingly general objects if specific ones do not have help of their own). The next step is a section on the applicability of the pattern to various problems, followed by a diagram of its structure, a list of the classes that participate in it, and the consequences of implementing this pattern. Each pattern also includes implementation issues and sample code, plus examples from situations where it’s known to be used.

The original patterns book spawned something of an industry in computer science. Hundreds of books are now available on software patterns; I even have several on my shelf that deal with Visual Basic .NET and C# design patterns.

Tip

A good place to start learning more about patterns (although fraught with dead links) is the Patterns Home Page at http://hillside.net/patterns/.

Why Patterns?

Patterns are complex and hard to describe. Some of the design patterns in the GOF book stretch over many pages of discussion and sample implementations (in C+ and Smalltalk). Just understanding the details of a pattern such as Observer can take quite a bit of study. So why take the time to make the study? Because if you’re working in systems architecture, the vocabulary of patterns can help you solve design problems quickly and with known-good solutions.

For example, consider the Observer pattern identified by the GOF. The Observer pattern shows you how to define a one-to-many dependency between an object and its dependents. When the object changes state, all of its dependents are notified and updated.

Now suppose your application deals with medical imaging data in a multiwindows UI. You might find yourself showing a rotating image in one window while simultaneously tracking the point of view numerically in another and updating a graph of transparency values in a third. A team without pattern experience might spend a long time working out a combination of objects, events, and algorithms to make everything work smoothly together. Or, if they were all familiar with the patterns in the original GOF book, it’s likely that someone would suggest the Observer pattern as an appropriate answer, and the discussion could move immediately to solving details like the unexpected update problem.

Design patterns make such discussions possible by giving the participants a shared vocabulary at a high level of abstraction. And by encapsulating the wisdom of members of the objectoriented design community who share decades of experience, design patterns help you benefit from that experience as well. You don’t need to reinvent the wheel if you have a design pattern that points out how well circular objects roll.

Patterns at Microsoft

A few years ago, I could have just left this section out of the book entirely. While Microsoft has been making excellent developer tools for a long time, its traditional attitude toward developers has been something like, “You’re smart people, you’ll figure this stuff out.” The release of a new version of Visual Basic or Visual C++ was an occasion for the Microsofties to go back to work on the next version while the rest of us figured out how to effectively use the current one.

That has largely changed since the release of the .NET Framework. Whether it’s feeling growing pressure from the Java camp, or whether it has just matured as an organization, Microsoft now offers substantial help to developers on the effective use of its products. In particular, you can gain a lot of knowledge with a visit to the Microsoft Patterns & Practices website (www.microsoft.com/resources/practices/).

The Patterns & Practices site provides an amazing amount of information. This ranges from entire books on topics like enterprise application patterns using Microsoft products (and you can download the books or order paper copies) to articles on best practices with Exchange Server and Active Directory. The patterns and practices here cut across both development and systems administration, just as Microsoft’s products do.

Tip

The Patterns and Practices Group posts some material for public review before it's officially published. You can keep up with the latest by visiting TheServerSide.NET at www.theserverside.net.

As a .NET developer, you should know in particular about the application blocks. The application blocks are fully developed chunks of reusable source code designed to solve particular problems. As I write this, the available application blocks include:

• Aggregation application block, for aggregating and transforming information from multiple sources

• Asynchronous Invocation application block, for agent-based asynchronous processing

• Caching application block, for caching information in distributed applications (note that for pure ASP.NET applications you should probably use the ASP.NET cache instead)

• Configuration Management application block, for securely reading and writing configuration information from a variety of sources

• Data Access application block, to simplify ADO.NET data access

• Exception Management application block, which provides an extensible framework for handling exceptions

• Logging application block, to enable distributed and asynchronous logging across an entire application

• Updater application block, which provides a “pull model” for updating desktop applications over a network

• User Interface Process application block, a model for writing UI and workflow processes as a distinct layer

You can find further information on these application blocks (and keep track of new application blocks) in the Patterns & Practices library at www.microsoft.com/resources/practices/completelist.asp.

Note

I’ll discuss the application blocks in more detail in Chapter 7, “Digging Into Source Code.”

---