Introduction - What are Design Patterns?
In order to understand what design patterns are, you first need a basic understanding of what software development really is. At its core, software design and development is nothing more than an attempt to solve a problem, usually a business or scientific one, using computing. This is the reason we refer to software as solutions. There have been millions of software solutions created to solve just as many problems. Many of these problems are identical, or similar enough to be nearly identical. In most cases, there are usually several potential solutions to any one of these problems. However, all solutions are not created equal, and the design for a solution is as important, if not more so, than the code that actually implements that solution. Problems change and evolve, and the solutions that solve those problems must be able to change and adapt easily if they are going to be of any real value. A good design supports the development of software that is able to adapt and change easily as the problem it is solving changes. A good design also provides the ability to reuse aspects of the solution in other places. This is the basis for why Design Patterns were created. They provide well defined, flexible, time tested solutions to the common problems that software attempts to solve.
Design Patterns are nothing new. They have been around for decades. They can be implemented in nearly any object oriented language. They require little more than an understanding of the problem you are trying to solve and an understanding of the pattern that solves that problem. As mentioned previously, they use designs that have been tried and tested and have shown themselves to be good solutions for the respective problems that they solve. There are literally hundreds of design patterns that have been defined. The most well known design patterns were defined by a group of talented software designers now known as �The Gang of Four�. Having a good repertoire of design patterns under your belt means that when you are presented with a problem, you don�t need to spend as much time figuring out how to solve it. You simply identify the problem and apply the pattern to it. They also give you a common base of terminology with which to describe your solution to other developers that are helping to solve the problem. If you are working with a group of developers that are familiar with design patterns, you don�t have to spend time explaining the intricacies of a solution; you need only specify the pattern you think best solves the problem. If everyone is familiar with the pattern you are proposing, you are much further along in the design process. Best of all, you know that because you used a pattern, your solution has a decent chance of being a good one.
Having said all that, let�s take a look at a design pattern, the Decorator Pattern. The decorator pattern solves problems where you have an object whose state or behavior can be modified by other objects that attach to or �decorate� it. Examples of this would be pizzas and their toppings, cars and their options, or streams and what to read or write to and the format they do it in. To help this make more sense, let�s take a look at a solution to a problem where we need the ability to decorate a base car with one or more non-standard features in order to come up with its sale price and description.
Using the code
- The first thing that we have to do is define a common type that will be used for both the cars themselves and the options we will use to decorate the cars with. This type will be the base for all of the cars that we will decorate. To do that, we create the following:
(It should be noted that it is not necessary to define both an interface for cars and an abstract, one or the other or both will suffice. What to use depends solely on the design considerations of your application.)
interface ICar
{
double Cost {get;}
string Description { get; }
}
abstract class Car:ICar
{
private double _cost = -1;
private string _desc = "abstract car.";
public virtual double Cost
{
get { return _cost; }
}
public virtual string Description
{
get { return _desc; }
}
}
- After we have defined the base functionality for our cars and their options, we need to define a base type for the options themselves:
abstract class CarOption:Car
{
double _cost = -1;
string _desc = "abstract car option";
public override string Description
{
get { return _desc; }
}
public override double Cost
{
get { return _cost; }
}
}
CarOption (above) implements Car and overrides its behavior. This type will be the base for all the classes that we will use to decorate a car with.
- Now, we will create a concrete implementation of a car:
class FerrariSpider:Car
{
double _cost = 250000;
string _description = "Ferrari Spider";
public override double Cost
{
get
{
return _cost;
}
}
public override string Description
{
get
{
return _description;
}
}
}
We have created a FerrariSpider class which implements our base Car class and overrides its behavior with the Ferrari specific behavior, namely the cost and desciption of a Ferrari Spider with no options.
- Now, we need to define some options that we want to decorate our Ferrari with:
We are going to create Turbo, Alloy Wheels, and Leather options for our Ferrari (or any other car that we might want to use them on).
class OptionAlloyWheels : CarOption
{
double _cost = 4564.42;
string _description = "Alloy Wheels, ";
Car _car;
public OptionAlloyWheels(Car car)
{
_car = car;
}
public override double Cost
{
get
{
return _car.Cost + _cost;
}
}
public override string Description
{
get
{
return _car.Description + _description;
}
}
}
class OptionTurbo:CarOption
{
double _cost = 7000.24;
string _description = "Turbo, ";
Car _car;
public OptionTurbo(Car car)
{
_car = car;
}
public override double Cost
{
get
{
return _car.Cost + _cost;
}
}
public override string Description
{
get
{
return _car.Description + _description;
}
}
}
class OptionLeather : CarOption
{
double _cost = 1000;
string _description = "Leather Seats, ";
Car _car;
public OptionLeather(Car car)
{
_car = car;
}
public override double Cost
{
get
{
return _car.Cost + _cost;
}
}
public override string Description
{
get
{
return _car.Description + _description;
}
}
}
Each of our options implement our CarOption class and override its default behavior. Each option also has a local reference to a Car type that will be used to hold a reference to the car that is to be decorated. The car instance is handed to the option via the option�s constructor.
- All that is left to be done now is to create an instance of our spider and give it some options by decorating it with the various option classes that we have created.
class Program
{
static void Main(string[] args)
{
Car car = new FerrariSpider();
car = new OptionLeather(car);
car = new OptionAlloyWheels(car);
car = new OptionTurbo(car);
Console.WriteLine("Description-->" +
car.Description.TrimEnd(' ',','));
Console.WriteLine("Cost-->" +
car.Cost.ToString());
Console.ReadLine();
}
}
Running this should produce the following:
Why this is cool
Creating the cars and their options separate from each other makes them very reusable. Any option can be used to decorate any car so long as the specific car implements Car or ICar and the specific car option implements CarOption. Because each car and each option are encapsulated in their own classes, there is no danger of breaking other cars or options when modifications to a specific car or option is needed. For the same reason, we can add new cars and options without fear of breaking existing implementations. Options already defined can be easily reused for new cars that are created. Going the other way, if new options are defined for existing cars, there is no need to modify the code for the car itself. Decorating a car with options in this manner is very easy, and creates very clean, readable, maintainable code. All you have to do is create an instance of the car you want to decorate and pass its instance to the constructor of any option you want to decorate the car with.
History
- Jan-2-2006 -- Initial creation.
