Using Design Patterns to Solve Design Problems

[Previous] [Next]

Designing object-oriented systems can be challenging. As an architect, you must break down a system into objects based on the information you gathered primarily during the analysis phase. You can derive certain generalizations from the objects you identify that make it possible for you to define classes for each unique object in your system. You can then produce a class diagram using any standard notation you favor, such as Object Modeling Technique (OMT), Unified Modeling Language (UML), and so on. (For more information on object notation, see Appendix A.) This class diagram is a self-documenting, accurate generalization of how your system is structured.

You can use one of several approaches to break down a system into objects. One approach is to identify the nouns and the verbs in the system: the nouns are the objects, and the verbs are the object methods. Another approach is to mirror your design to that of the business process. In this case, each process is an object, and each process flow is the action performed on an object; therefore, process flows are object methods.

Many questions will arise as you break down a system into objects. For instance, to what granularity should you break down the process? Suppose you have identified a process that requires information in a system to be cleared by the legal department. We'll call this the Legal process. This process might be complicated enough to warrant the implementation of several smaller internal processes. Should each internal process be an object in your system, or should they be methods of one Legal object type?

Objects package data and functions. By default, data is private to an object. Interfaces of an object are an abstraction of the object's representation. Conversely, an object's data is encapsulated to the point where the data is not exposed by the object's interface. Exposing the internal representation of an object increases its vulnerability to its consumers. As a result of this exposure, you lose the benefit of encapsulation. The amount of encapsulation determines an object's independence—more independence means you have more flexibility to modify the object to improve its implementation or to change its behavior without regard for any adverse effects on its consumers. The decisions you make regarding granularity and encapsulation will determine the extent to which the benefits of the object-oriented methodology, such as reusability, scalability, extensibility, and so on, are realized in your system.

If you're not realizing these benefits, you have problems in your system design. These problems are most likely a result of your attempt to mirror your design from a functional perspective or a process-flow perspective. To fully gain reusability, scalability, and so forth, you must extend your thinking to include ideas that will produce solutions that address these benefits. These solutions are abstractions of ideas that can be reapplied to systems that are completely diverse in nature. There is no greater form of reusability.

Expert object-oriented programmers and architects are proficient because they can design systems within a specified context, yet they can identify problems in the design and reapply solutions devised from experience. "Design patterns" is the official term that articulates these solutions, and the concept was more formally introduced in Design Patterns by Gamma, et al (Addison-Wesley, 1994). That book raised awareness in the object-oriented programming community about how to devise solutions that result in system reuse, scalability, and extensibility, and has inspired me to write this book. I strongly recommend you read Gamma's book.

Design patterns formally document the object-oriented design solutions—whether they are organic or were previously undocumented or inaccessible—known by many experts. Thus, the design patterns presented in this book are not new solutions, but rather are popular and proven solutions that have been implemented by expert object-oriented programmers. One intention of this book is to make these solutions easily accessible to the Visual Basic object-oriented programmer.

For example, if you wanted to reuse the functionality of legacy procedural code or dynamically extend the functionality of existing classes located in a class library, you could employ the Adapter design pattern, as shown in Chapter 4. What if you wanted to persist the state of an object to a data source, such as a Microsoft SQL Server database, an ASCII text file, or a Microsoft Excel workbook? Regardless of the data source or the context of the system, the Repository design pattern would be an appropriate solution. (See Chapter 11.) These kinds of problems frequently manifest themselves in object-oriented designs in varying contexts to which design pattern solutions can be applied.