“Design Patterns 100″ is a prerequisite for .NET Developers.
(Part 4 – Excerpts from July 2010 – PhillyNJ.NET Presentation)
Continuing our discussion from Part-3 we ask.
What are the “Gang of Four” (GoF) Structural Patterns and where can we find them in the .NET Framework?
Let’s look at a list of the Strutural Patterns as defined by the GoF.
- Adapter Pattern– is used to match interfaces of different classes
- Bridge Pattern– is used to separate an object’s interface from its implementation
- Composite Pattern– Allows clients to treat individual simple and composite objects uniformly
- Decorator Pattern– adds responsibilities to objects dynamically and is used for extending the functionality of an existing class
- Façade Pattern– provides an interface that represents an entire subsystem making it easier to use
- Flyweight Pattern– is primarily used to support the sharing of a lot fine-grained objects
- Proxy Pattern– provides an object representing another object to control access to it
The Adapter Pattern is used to match interfaces of different classes
In the .NET Framework the Adapter pattern is used extensively in providing the ability for .NET clients to communicate with legacy COM components. As you know, there are significant differences between COM and .NET. These are handled via Runtime Callable Wrappers (RCW) which are implementations of the Adapter pattern. The Adapter adapts the COM interface to what .NET clients expect
The Bridge Pattern is used to separate an object’s interface from its implementation
The Bridge is a high-level architectural pattern and as such is not exposed by the .NET libraries themselves. But developers are not aware of this, but they use this pattern all the time. If you build an application that uses a driver to communicate with a database, like with ODBC, you’re using the Bridge pattern. ODBC is a standard API for executing SQL statements and represents the interface.
These Bridge design pattern classes are those that implement the API of the ODBC drivers. The ODBC architecture decouples an abstraction from its implementation so that the two can vary independently for the different database.
The Composite Pattern Allows clients to treat individual simple and composite objects uniformly.
The Composite pattern is widely used in the .NET Framework. Control classes are examples of this. The one for Windows apps is in the System.Windows.Forms namespace and the other is for ASP.NET apps in the System.Web.UI namespace. These Control classes support operations that apply to all Controls and their descendants in their respective environments, as well as operations that deal with child controls.
Windows Presentation Framework (WPF) also has many built-in controls that are examples of the Composite Pattern.
The Decorator Pattern adds responsibilities to objects dynamically and is used for extending the functionality of an existing class
Examples of the Decorator in the .NET Framework include a set of classes that are designed around the Stream class. The Stream class which is an abstract class that reads or writes a sequence of bytes from an IO device (disk, sockets, memory, etc). There are various implementations in the framework based on this class like BufferedStream and CryptoStream.
The new .NET Extension Methods are a closely related to the composite pattern as they also offer the ability to add functionality to an existing type. Similarly, attached properties and attached events which are used in WPF, also allow extending classes dynamically without changing the classes themselves.
The Façade Pattern provides and interface that represents an entire subsystem making it easier to use.
In the .NET Framework you’ll find numerous implementations of the Façade design pattern. It is used in scenarios where there is a need to present a simplified view over more complex set of types.
To discuss this properly we need to distinguish high-level architectural Facades and lower level component type facades. Microsoft has introduced its own terminology for the lower level façade types in component-oriented designs; they call these aggregate components.
In reality these are pure façades as they represent a higher level view of multiple lower level types and APIs. A classic example of an aggregate component is System.Diagnostics.EventLog which developers use all the time. Examples of high level include System.Web.Mail.SmtpMail, System.IO.SerialPort, System.Messaging.MessageQueue and System.Net.WebClient which provide simpler interfaces to shield the user from the complexities of the subsystem.
Ultimately the Facade Pattern is used through many design methodologies like Domain Driven Design and other areas of business objects as well as the presentation layer in an applications design.
The Flyweight Pattern is primarily used to support the sharing of a lot fine-grained objects.
It is a highly specialized design pattern. The Flyweight is used internally in the .NET Framework as string management techniques to minimize memory usage for immutable strings. An application example you would see implemented in word processors and graphical editors.
The Proxy Pattern provides an object representing another object to control access to it.
In .NET the Proxy pattern manifests itself in .NET Remoting infrastructure. Whenever an object requires access to an object in a different address space (app domain, process, or machine) a proxy is created that sends the request to the remote object and any data it might need.
Generally with proxies, the client is frequently not even aware that a proxy is at work. Clients applications use proxies to contact Web Services and WCF services which are auto-generated proxy objects.
(NEXT: Design Patterns 100-Part5 – Behavioral Patterns)