Design Patterns in VS .NET

Print QR in VS .NET Design Patterns

A design pattern describes a common problem found in an object-oriented system and provides a solution to that problem. The classic text Design Patterns (Addison-Wesley, 1995), by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, catalogs 23 of the most common and important patterns. A complete design pattern description includes the following elements: Pattern name Each pattern has a one- or two-word name that captures the abstraction of the pattern. Problem This describes the problem to be solved and defines when the pattern is applicable.

Solution The solution describes the classes, their responsibilities, and the collaborations among them. The solution is described in an abstract way that can be applied in many contexts. Consequences Every design is a balance of advantages and disadvantages. For example, a solution might be fast, but consume a large amount of memory. Or the design might be optimized for a particular set of data, but unable to handle changes to the data structure. While pattern descriptions often give concrete examples of known uses in software, the problem statement is unlikely to be an exact description of the problem you re trying to solve. After reading and using some patterns, you ll become familiar with the patterns and you ll recognize how your problem falls into the same pattern. Observer The exercises in this book and the .NET Framework objects you ve used have employed several patterns. By having some insight into the design, you ll better understand how to use the object and make predictions about how well the objects are going to work in your applications. In 11, you implemented the Singleton pattern. Now take a look at another pattern, the Observer. Problem The Observer pattern is concerned with how objects in an application behave. If you were writing a kennel reservation system, you might have three forms in your application: one to take reservations, one to present a diagram showing empty and full kennels, and one to list the number of reservations each night. As reservations are made and canceled, the forms with kennels and reservation totals must change also. How do you keep the forms synchronized, making sure that the two other forms are notified each time there is a change in the reservations Can you do this so that you can add more dependent forms without rewriting the reservation form Solution The solution is to identify the subject and the observers in the system. In this example, the reservation form is the subject. The other forms are considered observers; they watch for changes in the subject. The subject class maintains a list of the observers through two methods it provides, Attach and Detach. For its part, the observer class provides an Update method that is called by the subject whenever the subject changes. When the subject changes, the Notify method calls the Update method for each observer in its list of observers. The subject also provides a GetState method that allows the observer to extract the information needed from the subject. The design is shown in the following UML diagram:

This pattern is also known as publish-subscribe. The subject publishes notifications when it changes. The observers subscribe to receive notifications. Event-Handling and the Observer Pattern The event-handling protocol of Visual Basic .NET and Visual C# displays the hallmarks of the Observer pattern. Consider the Button class as the subject. The Button publishes

a Click event. Observers, usually forms, subscribe to the Click event of the Button. The Attach method is implemented as AddHandler in Visual Basic and += in C#. The Detach method is implemented as RemoveHandler in Visual Basic and = in C#. The Update method is implemented as a method in the form class, something like Button1_Click(object sender, System.EventArgs e). When the Click event is raised, each method assigned through AddHandler or += is called. Information about the Button is found in the sender argument of the event handler. Note that we don t actually know or care how event handling is implemented in the .NET Framework. Still, the Observer pattern provides an understanding of event handling that can make it easier to use and explain event-handling behavior.