Technology

Database normalization can essentially be defined as the practice of optimizing table structures. Optimization is accomplished as a result of a thorough investigation of the various pieces of data that will be stored within the database, in particular concentrating upon how this data is interrelated. An analysis of this data and its corresponding relationships is advantageous because it can result both in a substantial improvement in the speed in which the tables are queried, and in decreasing the chance that the database integrity could be compromised due to tedious maintenance procedures.

Before delving further into the subject of db normalization, an introduce a few terms that frequently arise when discussing this subject. To better illustrate the meaning of the respective terms, I’ll allude to a hypothetical database which contains information about a school scheduling system.

entity: The word ‘entity’ as it relates to databases can simply be defined as the general name for the information that is to be stored within a single table. For example, if I were interested in storing information about the school’s students, then ‘student’ would be the entity. The student entity would likely be composed of several pieces of information, for example: student identification number, name, and email address. These pieces of information are better known as attributes.

primary key: A primary key uniquely identifies a row of data found within a table. Referring to the school system, the student identification number would be the primary key for the student table since an ID would uniquely identify each student.

Note that a primary key might not necessarily correspond to one specific attribute. In fact, it could be the result of a combination of several components of the entity. For example, while a location could not be a primary key for a class, since there might be several classes held there throughout the day, the combined time and location would make a satisfactory primary key, since no two classes could be held at the same time in the same location. When multiple attributes are used to derive a primary key, this key is known as a concatenated primary key.

relationship: Understanding of the various relationships both between the data items forming the various entities and between the entities themselves forms the crux of database normalization. There are three types of data relationships that you should be aware of:

one-to-one (1:1) – A one-to-one relationship signifies that each instance of a given entity relates to exactly one instance of another entity. For example, each student would have exactly one grade record, and each grade record would be specific to one student.

one-to-many (1:M) – A one-to-many relationship signifies that each instance of a given entity relates to one or more instances of another entity. For example, one professor entity could be found teaching several classes, and each class could in turn be mapped to one professor.

many-to-many (M:N) – A many-to-many relationship signifies that many instances of a given entity relate to many instances of another entity. To illustrate, a schedule could be comprised of many classes, and a class could be found within many schedules.

foreign key: A foreign key forms the basis of a 1:M relationship between two tables. The foreign key can be found within the M table, and maps to the primary key found in the 1 table. To illustrate, the primary key in the professor table (probably a unique identification number) would be introduced as the foreign key within the classes entity, since it would be necessary to map a particular professor to several classes.

Entity-relationship diagram (ERD): An ERD is essentially a graphical representation of the database structure. These diagrams, regardless of whether they are built using the latest design software or scrawled on a napkin with a crayon, are immensely useful towards attaining a better understanding of the dynamics of the various database relationships.

There are many ways in which mathematics influences my programming:

Formal specification
Before discovering a solution — or, in order to properly understand an existing one — I need a sense of the scope and nature of the problem. To do this rigorously, I can approach the programming problem similarly to how I would a mathematical one. That is, specifying input parameters, protocols, types, flow, states, processes and outputs. (It also goes some way towards verification for correctness.)

Discrete structures
Every program I write involves concrete application of abstract discrete structure in mathematics — from ordered sequences to matrices to trees/graphs to state machines and automata. Sometimes I need to know the profile of underlying structures provided by systems I’m using, and at other times I need to compose or create them myself.

Numerical analysis
An important practical concern is the representation of continuous real numbers by binary digital computers. It can be a complicated field in itself, but still has ramifications for the everyday programmer, with issues like floating-point precision and accuracy, rounding error, etc.

Symbolic analysis and meta programming
Programming often involves symbolic analysis analogous to mathematics. Besides direct counterparts like symbolic integration etc., in programming we typically deal with arbitrary symbols and expressions. Tokenizing, parsing, compiling, interpreting, rewriting and transforming symbolic input is close to algebraic mathematics. Formal languages and abstract computing machines are among fundamental theory in computer science, as well as matters of practical engineering concern.

Functional programming
One style of expressing program code (which I’m partial to) relies on immutable data structures, deep call chains, first-class/higher-order functions, function composition, and referential transparency. These are properties in common with mathematical convention. Being comfortable with that way of thinking is an advantage.

Algorithms
Similarly, an understanding of algorithms from a theoretical perspective (along with discrete structures) is essential. Knowing the order and limits of an algorithm’s resource usage can help make crucial decisions about tradeoffs early in the development process. Having a sense of the shapes of growth curves — if not the calculus behind them — is related (e.g. it’s easy to underestimate exponential growth).

Pre-calc mathematics
Arithmetic is obviously useful in so many cases. Understanding number radix and number lines is necessary for understanding bounding, overflow and conversion error. Geometry and trigonometry help with graphical applications — from basic user interfaces to 3D games and digital cartography. Set theory is connected with everything from bitwise operations to cryptographic hashing to relational databases.

Statistics and modelling
Being able to manage large amounts of realistic data is an asset. Whether you want to aggregate logs to identify trends, or ensure your randomized algorithm is secure, or evaluate a given test for your data, some statistical confidence is necessary.

Domain knowledge
Software is often specific to a particular domain which may require, at a minimum, comprehending their branch of applied mathematics. e.g. business maths for commerce software, statistical techniques for social and medical software, calculus for science/engineering software, and so on.

Mathematical philosophy
Practicing and engaging with mathematics will, over time, help you develop taste — for a kind of elegance of expression and beauty of structure, which overlaps a great deal with programming. In more specific terms, it involves things like limiting scope, constructing and composing abstractions, building meaningful relations, testing truth, reducing terms and simplifying assumptions.

The basic point is that thinking logically, analytically and yet creatively the way a mathematician does is very much applicable to programming. I’m nothing like an expert in either mathematics or computing, but in my experience as a student and practitioner, it has been highly beneficial to my activities in both areas to recognize and cultivate their intellectual connections.

If you are new to design patterns, studying them can seem like a daunting task. The number and scope of design patterns has been steadily increasing since the publication of Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in 1995. In their book, they present 23 design patterns organized into three categories: 1) Creational, 2) Structural, and 3) Behavioral design patterns. Since then, they and other authors have described other classification schemes for these patterns. By examining design patterns within different classification strategies, you will give yourself a deeper insight into what they are and how to use them. As you gain familiarity with them, you can begin to use them in your projects. In this paper, we will summarize the 23 common design patterns within the three categories. It is intended to serve as a glossary that I will refer to in the future.

Abstract Factory

The Abstract Factory is intended to provide a single interface for clients to use when they need to create a family of related objects without having to specify concrete classes. For example, imagine a system that needs to implement platform-specific user interface objects (menus, toolbars, and so forth) for several different platforms. Abstract Factory simplifies the interface for the client by localizing all of the initialization strategies within a single class, the Abstract Factory. The pattern works to ensure that all the strategies can work together correctly.

To understand Abstract Factory, examine the class diagram shown in the following figure. Note that there are two separate hierarchies. The first represents the various abstractions the client has interest in. For each abstraction, there exists an abstract class definition (AbstractClass1, AbstractClass2, and so on), and the subclasses that provide the concrete implementations (ConcreteClass1A, ConcreteClass1B, and so forth). In the second hierarchy, an abstract AbstractFactory class is defined to provide the interface for each class that is responsible for creating the members of a particular family. For example, ConcreteFactoryB is responsible for creating objects from classes ConcreteClass1B, ConcreteClass2B, and the like. All the client needs to worry about is which family of objects it is interested in creating and calling the appropriate Factory method. Because the client only knows about the abstract interface, it can interact with objects from different families without having to know about their internal implementation details. This approach has the benefit that the family can be allowed to grow without the need to modify the client. The primary drawback of AbstractFactory is that it can limit your flexibility when you want to take advantage of a specific capability a family may have. This is because you must provide a common interface across all families, even if some of them do not have this capability.

Adapter

The Adapter is intended to provide a way for a client to use an object whose interface is different from the one expected by the client, without having to modify either. This pattern is suitable for solving issues that arise, for example, when: 1) you want to replace one class with another and the interfaces do not match, and 2) you want to create a class that can interact with other classes without knowing their interfaces at design time.

In the class diagram shown for Adapter in the following figure, the client wants to make a specific request of an object (Adaptee). Ordinarily, this would be accomplished by creating an instance of Adaptee and invoking SpecificRequest(…). In this case, however, the client cannot do so because the interfaces do not match (the parameter types are different). Adapter helps you address this incompatibility by providing classes that are responsible for redefining the data types on the client’s behalf. First, you create a custom Target class that defines methods using an interface expected by the client. And second, you create a custom Adapter that implements the interface expected by the Adaptee. The Adapter class subclasses the Target, and provides an alternate implementation of the client requests in terms that the Adaptee expects. Adapter overrides the Target method and provides the correct interface for Adaptee. This approach has the advantage that it does not lead to modifications in the client. Adapter is a structural pattern and you can use it to react to changes in class interfaces as your system evolves, or you can proactively use the Adapter pattern to build systems that anticipate changing structural details.

Bridge

The Bridge is intended to decouple an abstraction from its implementation so both can vary independently. For example, a significant maintenance headache entails the coupling that occurs between custom classes and the class libraries they use. Bridges are useful for minimizing this coupling by providing an abstract description of the class libraries to the client. For example, a typical abstraction could be created for displaying a record set (DisplayRecordset as an Abstraction). The DisplayRecordset class could then be implemented using a variety of user interface elements (data grids, data lists, etc.), or with different formats (chart, table, and so forth). This has the effect of keeping the client interface constant while you are permitted to vary how abstractions are implemented. In addition, you can localize the logic used to determine which implementation and which abstraction the client object should use. The remaining client methods only need to know about the abstraction.

To illustrate the Bridge Pattern, consider the class diagram displayed in the following figure. The client would have a method such as “SetupAbstraction(…)” that would be responsible for determining which implementation to use for the abstraction. Then the client is free to interact with the Abstraction and the proper implementation class will respond.

Builder

Builder is used to separate the construction of complex objects from their representation so the construction process can be used to create different representations. The construction logic is isolated from the actual steps used to create the complex object and, therefore, the construction process can be reused to create different complex objects from the same set of simple objects. This tends to reduce the size of classes by factoring out methods that are responsible for constructing complex objects into a single class (called a Director) that is responsible for knowing how to build complex objects. In addition, Builder can be used when you want to create objects in a step-wise manner depending on parameters you acquire along the way.

The class diagram shown in the next figure shows the client instantiates the Builder and Director classes. The Builder represents the complex object in terms of simpler objects and primitive types. The client then passes the Builder object, as a parameter, to the Director’s constructor, which is responsible for calling the appropriate Builder methods. An abstract AbstractBuilder class is created to provide the Director with a uniform interface for all concrete Builder classes. Thus, you can add new types of complex objects by defining only the structure (Builder) and reuse the logic for the actual construction process (Director). Only the client needs to know about the new types. The Director simply needs to know which Builder methods to call.

Chain of Responsibility

One of the tenets of software engineering is to keep objects loosely coupled. The Chain of Responsibility is intended to promote loose coupling between the sender of a request and its receiver by giving more than one object an opportunity to handle the request. The receiving objects are chained and pass the request along the chain until one of the objects handles it.

The class diagram, as illustrated in the following figure, shows that the client instantiates the Request and passes it as a parameter to an instance of the Handler. Each concrete handler is responsible for implementing an action to take on the Request object, and to maintain a reference to the next handler in the chain. An abstract Handler is defined to provide a uniform interface for the concrete handlers. The client is responsible for creating Request objects and then passing them to the first handler in the chain. The chain (Handler1 -> Handler2 -> Handler3, and so forth) can be set by the client by calling the SetSuccessor(…) for each handler it instantiates.

Command

The Command pattern is intended to encapsulate a request as an object. For example, consider a window application that needs to make requests of objects responsible for the user interface. The client responds to input from the user by creating a command object and the receiver. It then passes this object to an Invoker object, which then takes the appropriate action. This allows the client to make requests without having to know anything about what action will take place. In addition, you can change that action without affecting the client. Practical uses for Command are for creating queues and stacks for supporting “undo” operations, configuration changes, and so on.

As shown in the following class diagram, the client instantiates the Receiver class and passes it as an argument to the constructor of the ConcreteCommand class. The Receiver is responsible for carrying out the specific actions required and fulfilling the request. An abstract class is defined to provide a uniform interface for the concrete Command class. The concrete Command classes are responsible for executing the appropriate methods on the Receiver. The client uses the Invoker to ask the Command when to carry out the request. One drawback to the Command pattern is that it tends to lead to a proliferation of small classes; however, it does lead to simpler clients for supporting modern user interfaces.

Composite

The Composite is intended to allow you to compose tree structures to represent whole-part hierarchies so that clients can treat individual objects and compositions of objects uniformly. We often build tree structures where some nodes are containers of other nodes, and other nodes are “leaves.” Instead of creating separate client code to manage each type of node, Composite lets a client work with either using the same code.

As the class following diagram shows, the composite pattern consists of an abstract class called a Component, which provides interface for nodes and leaves alike. In addition, the Component may also define a default implementation when it is appropriate. The Leaf and Composite classes provide their own implementations, as well. The key to this pattern is the Composite class, which uses a collection to create complex objects from other objects (Leaves or other Composites). In addition, the composite object provides a way to iterate the composition to execute operations on the individual objects in the composition.

Decorator

Ordinarily, an object inherits behavior from its subclasses. The decorator pattern is intended to give you a way to extend the behavior of an object, and you can also dynamically compose an object’s behavior. Decorator allows you to do so without the need to create new subclasses.

When you examine the next class diagram, you will notice there are two basic types of classes. The Component, whose behavior you want to extend, and the Decorator, which implements the extended behavior. You can have any number of Components and Decorators. You also provide abstract classes for both types of classes so the client has a common interface. The key to the Decorator is the SetComponent(…) method, which takes a component as an argument. The client is responsible for instantiating the Component and passing it to the Decorator’s constructor. The client is then free to utilize the Component’s new methods, as implemented in the Director. A really nice feature of the Decorator pattern is that you can decorate specific instances of objects. This is difficult to do if you subclass your components directly.

Facade

With the many classes and subsystems we use, it is important to isolate our software and reduce coupling. The Facade Pattern is intended to provide a unified interface to a set of interfaces in a subsystem. The Facade defines a higher-level interface that makes the subsystems easier to use. There are several benefits to Facade. First, it provides developers with a common interface to the subsystem, leading to more uniform code. Second, it isolates your system and provides a layer of protection from complexities in your subsystems as they evolve. Third, this protection makes it easier to replace one subsystem with another because the dependencies are isolated. The main disadvantage of Facade is that it tends to limit your flexibility. You are free, however, to instantiate objects directly from the subsystems.

As the following class diagram shows, the facade pattern provides the client with a uniform interface to the subsystem. Often the code that is inside a facade would have to be inside client code without the facade. The subsystem code beneath the facade can change without affecting the client code.

Factory Method

When developing classes, you always provide constructors for your clients’ use. There are certain circumstances in which you do not want your clients to know which class out of several to instantiate. The Factory Method is intended to define an interface for clients to use to create an object, but lets subclasses decide which class to instantiate. Factory Methods let a class defer instantiation to subclasses.

As the next class diagram shows, the pattern uses two types of classes. The Product classes, which are the classes that make up your application, and the Creator classes, which are responsible for defining the Factory methods used to create instances of Product objects on the clients behalf. The Creator class defines the factory method, which returns an object of type Product. The patterns uses abstract Product and Creator classes to provide the client with a uniform interface. Concrete classes provide the appropriate implementation for their respective base class. In addition, Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object. It may also call the factory method to create a Product object. Any of these approaches can be used to balance the forces at work on your project.

Flyweight

The Flyweight pattern is useful for situations where you have a small number of different objects that might be needed a very large number of times—with slightly different data that can be externalized outside those objects. The Flyweight is intended to use sharing to support large numbers of fine-grained objects more efficiently and reduce resource usage. The pattern makes reference to an object’s intrinsic data, that makes it unique and extrinsic data, that gets passed in as parameters. This pattern is useful for applications in which you may need to display icons to represent folders or some other object and don’t want to add the overhead of creating new icons for each individual folder. An example would be the right pane of Microsoft Windows Explorer. In this type of situation, it may be better to share instances of a class. This pattern differs from a Singleton because you can have a small number of Flyweights, such as one for every different icon type.

In the next class diagram, the Flyweight class is abstract and defines an interface for all Flyweights to implement behavior to act on extrinsic data. The Concrete Flyweight implements the Flyweight interface and maintains the intrinsic data. A ConcreteFlyweight object must be sharable. Any data it stores must be intrinsic; that is, it must be independent of the ConcreteFlyweight object’s context. Not all Flyweight subclasses need to be shared, so you can also create classes for unshared flyweight data, as well. The client is responsible for maintaining references to the flyweight objects and the extrinsic data (data that makes the instance unique).

Interpreter

Some applications provide support for built-in scripting and macro languages so users can describe operations they can perform in the application. The Interpreter is intended to provide you with a way to define a representation of the grammar of a language with an interpreter that uses the representation to interpret sentences in the language.

The following class diagram shows that you define two types of classes. A Context is responsible for the data that is accessible to the Interpreter. You also define an abstract Expression class that declares an abstract Interpret operation. Terminal and Nonterminal concrete classes are defined that inherit the abstract Expression interface. They provide the implementation for the Interpet(…) function, which is responsible for the interpret operation to be performed on the terminal and nonterminal tokens, respectively, for the abstract tree syntax. In the case of nonterminal expressions, you need to define a class for each rule in your grammar. The client is responsible for creating the abstract syntax tree using the terminal and nonterminal expression objects as appropriate, and calling the interpret(…) method. Because the different expressions conform to the expression interface, the client can interpret the complete expression without knowing the structure of the abstract tree.

Iterator

The Iterator pattern provides a client with a way to access the elements of an aggregate object sequentially without having to know the underlying representation. Iterator also provides you with a way to define special Iterator classes that perform unique processing and return only specific elements of the data collection. The Iterator is especially useful because it provides the client with a common interface so it doesn’t need to know anything about the underling data structure.

The following class diagram shows the Iterator pattern consists of a Node Collection, a Node class, and the Iterator classes. An abstract Iterator class provides a uniform interface for the various concrete Iterator classes to implement. The client creates instances of the Node collection and adds Nodes objects as appropriate. Finally, it creates an instance of the appropriate Iterator and uses it to traverses the node collection accordingly. With this technique, you can build a family of generic methods for traversing node collections.

Mediator

Applications with many classes tend to become brittle as communication between them becomes more complex. The more classes know about each other, the more difficult it becomes to change the software. Mediator is intended to define an object that encapsulates how a set of objects interacts. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and lets you vary their interaction independently.

The next class diagram shows that Mediator consists of two types of classes, Colleague and Mediator. Colleagues are the objects from your application that you want to interact, and Mediators are responsible for defining the interactions. In the Mediator class, you define the methods that act on the Colleague objects and a method for introducing Colleagues. The client is responsible for instantiating the appropriate Colleague objects and the Mediator, and passing the Colleague objects to the Mediator’s IntroduceColleagues(…) method. The client can then invoke the appropriate method on the Colleague objects. The Mediator assures the requests are passed to the interacting Colleagues. The main benefit of Mediator is that the interactions between relating objects are removed from the objects themselves and localized in the Mediator.

Memento

Client code often needs to record the current state of an object, without being interested in the actual data values (for example,, supporting undo operations). To support this behavior, we can have the object record its internal data in a helper class called a Memento, and the client code can treat this object like a black box for storing its current state. Then, at some later point in time, the client can pass the Memento back into the object, to restore it to a previous state. The Memento provides you with a way to capture and externalize an object’s internal state so that it can be restored at a later time. It does this by violating encapsulation and without making the object responsible for this capability itself.

The class diagram for memento (see the next figure) shows the Originator as the object whose state you want to persist. You need to define the Memento class, which is responsible for storing the internal state or the Originator object. Finally, you define a Caretaker class that is responsible for protecting the Memento object. The key to Memento is that the Originator defines methods for creating and setting the Memento. In addition, Memento objects implement dual interfaces: one for the Originator and one for the Caretaker. Caretaker sees a narrow interface to the Memento—it can only pass the Memento to other objects. Originator, in contrast, sees a wide interface, one that lets it access all the data necessary to restore itself to its previous state. Ideally, only the originator that produced the memento would be permitted to access the memento’s internal state. The client decides when it wants to store the state of the originator. It does so by invoking the Originators CreateMemento(…) method. The state can be restored by invoking SetMemento(…).

Observer

The Observer pattern is useful when you need to present data in several different forms at once. The Observer is intended to provide you with a means to define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The object containing the data is separated from the objects that display the data and the display objects observe changes in that data.

As the next class diagram shows, there are basically two different types of objects: a Subject and an Observer. The Subject corresponds to the data object whose state you want to track. The Observer is the object that is interested in changes in the Subject object data. To set up the pattern, Subject classes implement a method for registering Observers and for attaching and detaching them from a collection object. In addition, Subjects also implement GetState(…) and SetState(…) methods for the Observer to call. Finally, you also need a notify(…) method to notify all registered Observers when the data has changed. In addition to the Subject, you can also create Subject subclasses to store the Subject’s state to satisfy any special requirements of concrete Observers. For Observers, you define a custom abstract Observer class to provide clients with a uniform interface, and subclass the implementation details.

Prototype

The Prototype is a simple pattern intended to provide you with a way to dynamically select which object to instantiate, and to return a clone of a prototypical object. This pattern is useful in applications that use a graphical toolbox to create instances of subclasses that represent the objects used by an application.

As the following class diagram shows, the pattern consists of an abstract Prototype class that defines a Clone(…) method that all concrete Prototypes implement. The client simply calls the Clone(…) method for the specific concrete Prototype it requires.

Proxy

The Proxy is intended to provide you with a way to use a surrogate or placeholder to another object in order to control access to it. This pattern is useful for situations where object creation is a time consuming process and can make an application appear sluggish. A proxy object can provide the client with feedback while the object is being created. Proxy can also be used to provide a more sophisticated reference to an object. For example, the proxy object can implement additional logic on the objects behalf (security, remote procedure calls, an so forth).

The next class diagram shows the pattern consists of two types of classes. The Subject is the actual object the client is interested in. An abstract Subject class is defined to provide both the Proxy and the client with a uniform interface to the Actual Subject classes. The Request(…) method is responsible for creating and returning an instance of the Subject. The Proxy overrides this method with its own implementation and manages the reference to the ActualObject class. The Proxy can also implement its own functionality when instantiating the ActualObject class. The client is responsible for selecting and instantiating the Proxy, and some time later, making a call to the Request(…) method. The Proxy responds by returning the actual object.

Singleton

There are a number of situations in programming where you need to assure that you have only one instance of a class. Print spoolers, window managers, and so forth, are examples of Singletons. The Singleton is intended to provide a way to ensure that a class provides one instance of itself, and to provide a global point of access.

The following class diagram shows the Singleton is a simple pattern. The Singleton class is responsible for instantiating itself and passing that instance on to the client. Therefore, the access modifier for the Singleton constructor must be either private or protected so the client cannot call the constructor itself. The Singleton also provides a method that returns the sole instance of itself to the client. The first time the client requests an instance, the Singleton will create that instance internally and store it as a private member. Each subsequent call from the client will return that instance.

State

The State pattern is useful when you want to have an object represent the state of an application, and you want to change the state by changing that object. The State pattern is intended to provide a mechanism to allow an object to alter its behavior in response to internal state changes. To the client, it appears as though the object has changed its class. The benefit of the State pattern is that state-specific logic is localized in classes that represent that state.

The next class diagram shows how to implement the State pattern. You define a Context class and an abstract class, State class, which your custom State handlers can implement. The Context class is responsible for calling the appropriate state handlers. The client instantiates the Context class and calls the Request(…) method with the appropriate arguments. The Request(…) method then determines which state handler should handle the request and passes the data to the Handle(…) method. The benefit of the State pattern is deeply nested or complex if statements are localized in the Context class instead of the client. Therefore, when the state of an application has to change in response to use input, the client merely passes this data to the Context object and the appropriate updates to the application state are made.

Strategy

The Strategy pattern is very useful for situations where you would like to dynamically swap the algorithms used in an application. If you think of an algorithm as a strategy for accomplishing some task, you can begin to imagine ways to use Strategy. Strategy is intended to provide you with a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. Strategy lets the algorithms vary independently from clients that use them.

The following class diagram shows the Strategy pattern basically consists of a context class and a set of strategy classes. You define an abstract strategy class that your custom strategy classes can implement. Each strategy object implements the algorithm that makes it unique. The client instantiates the strategy class and passes it as an argument when it calls the constructor of the context class. The client is then able to call methods on the context object and any strategy specific methods as necessary. Because the context creates an instance of the abstract Strategy, the client is effectively using polymorphism to call strategy-specific methods on the context object.

Template Method

The Template Method is a simple pattern. You have an abstract class that is the base class of a hierarchy, and the behavior that is common to all objects in the hierarchy is implemented in the abstract class. Other details are left to the individual subclasses. The Template pattern is basically a formalism of the idea of defining an algorithm in a class but leaving some of the details to be implemented in subclasses. Another way to think of the Template Method is that it allows you to define a skeleton of an algorithm in an operation and defer some of the steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

The next class diagram shows the Template method simply consists of an abstract class and subclasses. These classes define a set of primitive behaviors that make up a specific piece of functionality in the application. Behaviors common to all objects (TemplateMethod(..)) are implemented in the abstract class. Subclasses are free to provide an alternate implementation (overriding a method), or to provide methods specific to a particular concrete class (such as Step1(…) and Step2(…)).

Visitor

The Visitor pattern uses an external class to act on data in other classes. This is a useful approach to you when you have a polymorphic operation that cannot reside in the class hierarchy. Visitor is also a useful way to extend the behavior of a class hierarchy without the need to alter existing classes or to implement the new behavior in every subclass that requires it.

The following class diagram shows that the Visitor pattern consists of two different types of classes, Elements and Visitors. Elements are the objects your application uses and Visitors are encapsulated behaviors that are required for each concrete Element. Each Element must implement the Accept( ) method, which takes Visitor as an argument. In addition, each Visitor must provide an implementation of the VisitElementX( ) method for each element in the object structure. The client acts to instantiate the element class and the visitor class. The client then passes the visitor object to the element’s Accept( ) method, and then calls the elements methods to have it perform operations. The actual action that gets performed is determined by which visitor class was instantiated by the client.

Software professionals may be familiar with the term “Design Patterns,” but many have no idea of where they come from and what they truly are. Consequently, some do not see the value and benefits design patterns bring to the software development process, especially in the areas of maintenance and code reuse. This article will bridge this gap by defining design patterns from a historical perspective. It will also summarize the salient features of a typical design pattern and arrive at a working definition so that you will know what they are and what to expect when you incorporate them into your designs. Finally, it will explicitly summarize the benefits design patterns bring to software development and why you should incorporate them into your work. Subsequent articles will present more detailed descriptions of some of the more common design patterns, and how they can be applied to software development on the .NET platform.

What Are Design Patterns and Where Do They Come From?

Design patterns are commonly defined as time-tested solutions to recurring design problems. The term refers to both the description of a solution that you can read, and an instance of that solution as used to solve a particular problem. (I like the analogy of comparing design patterns to a class and an object instance of the class. Each is a different way to represent a thing.) Design patterns have their roots in the work of Christopher Alexander, a civil engineer who wrote about his experience in solving design issues as they related to buildings and towns. It occurred to Alexander that certain design constructs, when used time and time again, lead to the desired effect. He documented and published the wisdom and experience he gained so that others could benefit. About 15 years ago, software professionals began to incorporate Alexander’s principles into the creation of early design pattern documentation as a guide to novice developers. This early work led others to also write about design patterns and culminated in the publication of Design Patterns: Elements of Reusable Object-Oriented Software in 1995 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. This book is considered to be the “coming out” of design patterns to the software community at large and has been influential in the evolution of design patterns since. Design Patterns described 23 patterns that were based on the experience of the authors at that time. These patterns were selected because they represented solutions to common problems in software development. Many more patterns have been documented and cataloged since the publishing of Design Patterns. However, these 23 are probably the best known and certainly the most popular.

Design patterns are represented as relationships between classes and objects with defined responsibilities that act in concert to carry out the solution. To illustrate a design pattern, consider the Adapter pattern, one of the original 23 patterns described in Design Patterns. Adapter provides a solution to the scenario in which a client and server need to interact with one another, but cannot because their interfaces are incompatible. To implement an Adapter, you create a custom class that honors the interface provided by the server and defines the server operations in terms the client expects. This is a much better solution than altering the client to match the interface of the server.

The design pattern community is growing both in membership and coverage. The pattern literature describes new patterns that solve emerging issues related to technical advancements. As a software professional, you are the beneficiary of this body of knowledge. To use these patterns, you will need to learn them and become familiar with them so you will know which pattern to pull from your toolbox when a design issue arises. Many patterns have been documented over the years. They have been classified in different ways by different authors. Take the time to learn different ways to classify design patterns because you will gain greater insight into them. As you learn more and more patterns, it would be a good idea to develop your own classification system; one reflecting the way you utilize them.

Structure of a Design Pattern

Design pattern documentation is highly structured. The patterns are documented from a template that identifies the information needed to understand the software problem and the solution in terms of the relationships between the classes and objects necessary to implement the solution. There is no uniform agreement within the design pattern community on how to describe a pattern template. Different authors prefer different styles for their pattern templates. Some authors prefer to be more expressive and less structured, while others prefer their pattern templates to be more precise and high grain in structure. We will use the template first described by the authors of Design Patterns to illustrate a template.

This template captures the essential information required to understand the essence of the problem and the structure of the solution. Many pattern templates have less structure than this, but basically cover the same content.

Benefits of Design Patterns

Design patterns have two major benefits. First, they provide you with a way to solve issues related to software development using a proven solution. The solution facilitates the development of highly cohesive modules with minimal coupling. They isolate the variability that may exist in the system requirements, making the overall system easier to understand and maintain. Second, design patterns make communication between designers more efficient. Software professionals can immediately picture the high-level design in their heads when they refer the name of the pattern used to solve a particular issue when discussing system design.