“Ensure a class only has one instance, and provide a global point of access to it.”

Design Patterns: Elements of Reusable Object-Oriented Software

The Singleton pattern is something really simple. Let’s assume you have a class, which represents your data access layer, as a whole. As you might guess, a DAL object can grow quite large, especially when it stores disconnected data, such as in the case of a DataSet. There might be good reasons to have multiple ones instantiated of them, but maybe that’s not the best idea ever.

This is when Singleton pattern comes to place. It ensures that only one and only instance can live of a specific class, and that instance is accessible for every part of your code which needs it for its work. Implementing this behavior in code is very easy, consider the following example:

public sealed class MySingleton
                public static readonly MySingleton SoleInstance = new MySingleton();
                //rest of the class

Continue reading



“Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.”

Design Patterns: Elements of Reusable Object-Oriented Software

Instantiating a class multiple times can be resource intensive, and can result in repeating the very same code multiple times. Sometimes it is more convenient to copy or clone your existing objects. Fortunately, the .NET Framework has built-in support for these cases, the aforementioned IClonable interface. This interface contains only one method, the Clone, which returns Object. So any time you need to use the Prototype pattern, just implement IClonable, and you are good to go.

A little about the idea: imagine that you are working with a complex class, such as one representing a table of data from a SQL database. You’d do something with it, then you’re in the need of the same data again. Instead of rebuilding the whole object again, you should clone the first one, and call your methods on it. It saves you from writing the same code twice, and the cost of creating a new object on the heap.

To be straightforward, let’s enlist the participants here, too:
Continue reading

Factory Method

“Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.”

Design Patterns: Elements of Reusable Object-Oriented Software

A factory method is a method which creates and returns an object. I think this is quite simple, and there are countless examples in the .NET Framework for it. What is it good for? Well, it enforces encapsulation. You have a method to create objects, and it’s far more flexible than just instantiating them through constructors.

The key players in this pattern are:

  • Creator: the abstract base class, which declares the factory method, which returns a type of Product.
  • ConcreteCreator: a concrete implementation of the Creator class, which overrides the factory method in it.
  • Product: the abstract base class or interface for your product types, what creator returns.
  • ConcreteProduct: the concrete implementation of the base Product class, what the ConcreteCreator classes return.

A common practice in the Factory Method pattern is to let the method accept a member of an enumeration, and based on the passed member, return different kinds of objects. Also, it’s quite common to make the constructor of the ConcreteProduct class private, thus enforcing clients to use the factory method.

Continue reading


“Separate the construction of a complex object from its representation so that the same construction process can create different representations.”

Design Patterns: Elements of Reusable Object-Oriented Software

Just like the Abstract Factory pattern, Builder is also a creational pattern, with the same goal: create another (in this case, more complex) objects. To stick with the previous data access example, imagine that you have a class with many properties to set, for example, a DbCommand derivate: SqlCommand. You can build SqlCommand objects with the SqlCommandBuilder class, a derivate of DbCommandBuilder. Now SqlCommandBuilder is very intelligent, it builds a complete command object from just a SqlDataAdapter object (which has everything that a command should need: a connection object and a select command object).
Continue reading

Abstract Factory

“Provide an interface for creating families of related or dependent objects without specifying their concrete classes.”

Design Patterns – Elements of Reusable Object-Oriented Software

So let’s begin revising the “traditional” object-oriented design patterns. I’m going to stick closely to the book, so the order of posts will be the same as the order in the book.

Abstract Factory is a creational pattern. It means that its sole purpose of such a class is to create another objects/classes. An Abstract Factory pattern has the following participants:

  • Abstract base factory class/interface
  • Concrete factory subclasses derived from the base class, implements the interface
  • Abstract product: the abstract base class of the products to be created
  • Concrete product: the concrete implementation of the abstract product.
  • Client: uses the abstract factory and the abstract product classes, without further knowledge of their concrete implementations.

Continue reading