Discover the Design Patterns

Behind the Scenes: Discover the Design Patterns You're Already Using in the .NET Framework :: Rob Pierry -- MSDN Magazine, July 2005

* Common design patterns used in .NET Framework classes
* Patterns used to implement the ASP.NET programming model and request pipeline
* How patterns make programming tasks faster and easier

Microsoft has placed increasing emphasis on design patterns. If you are unfamiliar with patterns, suddenly being inundated with new terms and foreign-looking UML diagrams can be overwhelming. This emphasis on patterns, however, doesn't represent a shift in methodology so much as a change in vocabulary. The Microsoft® .NET Framework base class library (BCL) already makes extensive use of patterns, and you are probably familiar with the most common ones, even though you might not realize it yet.

In this article, I'll cover a basic overview of several common design patterns and how they are used in the BCL and other areas of the .NET Framework. In doing so, you can discover some of the motivation for why the Framework is designed the way it is, as well as make the abstract concepts of the patterns themselves more intuitively understandable.

Most of the patterns I'll be covering come from the canonical reference, Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, (Addison-Wesley, 1995). These authors are collectively known as the Gang of Four. The Gang of Four didn't invent these patterns, but they documented and formalized the good work others had been doing since the beginning of software development.

Observer Pattern

Good object-oriented design emphasizes both encapsulation and loose coupling. In other words, classes should keep internal details private and also minimize their strict dependencies. In most applications, classes don't work in isolation; they interact with many other classes. A common scenario of class interaction occurs when one class (the Observer) needs to be notified when something changes in another (the Subject). For example, several Windows® Forms controls might need to update their display after a button is clicked. A simple solution would be to have the Subject call a specific method of the Observer whenever a change in state occurs. This introduces a host of problems, however. Now, since the Subject needs to know which method to call, it is tightly coupled to that specific Observer. Furthermore, if you need to add more than one Observer, you have to continue to add code for each method call to the Subject. If the number of Observers changes dynamically, this gets even more complex. You'll quickly end up with a brittle mess that's difficult to maintain.

Iterator Pattern

Many programming tasks involve manipulating collections of objects. Whether these collections are simple lists or something more complex such as binary trees, you'll often need some way to get access to each object in the collection. In fact, depending on the collection, you may want several ways to access each object such as front to back, back to front, preorder or postorder. To keep the collection simple, the traversal code itself is often in its own class.

Decorator Pattern

Any useful executable program involves either reading input, writing output, or both. Regardless of the source of the data being read or written, it can be treated abstractly as a sequence of bytes. .NET uses the System.IO.Stream class to represent this abstraction. Whether the data involves characters in a text file, TCP/IP network traffic, or something else entirely, chances are you will have access to it via a Stream. Since the class for working with file data (FileStream) and the class for working with network traffic (NetworkStream) both inherit from Stream, you can easily write code that processes the data independent of its origins.

Adapter Pattern

One of the strengths of the .NET Framework is backward compatibility. From .NET-based code you can easily call legacy COM objects and vice versa. In order to use a COM component in your project, all you have to do is add a reference to it via the Add Reference dialog in Visual Studio .NET. Behind the scenes, Visual Studio® .NET invokes the tlbimp.exe tool to create a Runtime Callable Wrapper (RCW) class, contained in an interop assembly. Once the reference has been added (and the interop assembly has been generated for you), the COM component can be used like any other class in managed code. If you were looking at code someone else had written without seeing the list of references (and without examining metadata associated with the classes or their implementation), you would be unable to tell which classes were written in a .NET-targeted language and which were COM components.

The magic that makes this happen is contained in the RCW.

Factory Pattern

There are many cases in the Framework where you can obtain a new instance of a struct or class without calling its constructor yourself. The System.Convert class contains a host of static methods that work like this. To convert an integer to a Boolean, for example, you can call Convert.ToBoolean and pass in the integer. The return value of this method call is a new Boolean set to "true" if the integer was non-zero and "false" otherwise. The Convert class creates the Boolean for you with the correct value. Other type conversion methods work similarly. The Parse methods on Int32 and Double return new instances of those objects set to the appropriate value given only a string.

This strategy for creating new object instances is known as a Factory pattern.

Strategy Pattern

Both Array and ArrayList provide the capability to sort the objects contained in the collection via the Sort method. In fact, ArrayList.Sort just calls Sort on the underlying array. These methods use the QuickSort algorithm. By default, the Sort method will use the IComparable implementation for each element to handle the comparisons necessary for sorting. Sometimes, though, it is useful to sort the same list in different ways. For example, arrays of strings might be sorted with or without case sensitivity. To accomplish this, an overload of Sort exists that takes an IComparer as a parameter; IComparer.Compare is then used for the comparisons. This overload allows users of the class to use any of the built-in IComparers or any of their own making, without having to change or even know the implementation details of Array, ArrayList, or the QuickSort algorithm.

Composite Pattern in ASP.NET

The ASP.NET request/response pipeline is a complex system. Patterns are used in the design of the pipeline itself and in the control architecture to effectively balance its performance with extensibility and ease of programming.

When dealing with collections of objects, there are often operations that are appropriate for both a single object and the entire collection. Think about an ASP.NET control. A control may be a simple single item like a Literal, or it could be composed of a complex collection of child controls, like a DataGrid is. Regardless, calling the Render method on either of these controls should still perform the same intuitive function.

When each item in the collection might itself contain collections of other objects, the use of the Composite pattern is appropriate. Composite is an easy way to represent tree-like collections without having to treat parent and leaf nodes differently.

The canonical example of Composite relies on an abstract base class, Component, that contains both methods for adding and removing children, and the operations common among parents and children.

Template Method Pattern

When the standard library of ASP.NET controls doesn't meet your needs, you have several options on how to create your own. For simple controls that only need to be used in a single project, a user control is often the best choice. When the control is to be used in several Web applications or requires more functionality, a custom server control may be a better fit.

Intercepting Filter Pattern

Once a request has made it into an HttpApplication, it passes through any number of IHttpModules. Each module is independent and has only a limited amount of control over the order in which it is invoked. The HttpApplication class exposes a sequence of events that get raised as the request makes its way through processing. These events include BeginRequest, AuthenticateRequest, AuthorizeRequest, and EndRequest. When the HttpApplication loads a module, it calls the Init method of the IHttpModule interface, allowing the module to register for any of the events it cares about. As a given request is handled, the events are raised in the appropriate order and all registered modules get a chance to interact with the request. The module can therefore control the stage at which it gets invoked, but not the exact order within that stage.

Page Controller Pattern

System.Web.UI.Page implements a core part of the programming model for ASP.NET. Whenever you want to add a logical page to a Web application, you can create a Web Form (represented by an ASPX file and its codebehind). You can then write code to handle the specific demands of the new page, whether through handling page-level events, displaying a set of controls, or loading and manipulating data. Each logical page in the application has a corresponding Web Form that controls its behavior and regulates its presentation.

Several of the patterns employed by this process are more thoroughly documented in another standard reference for patterns, Martin Fowler's Patterns of Enterprise Application Architecture (Addison-Wesley, 2002).