Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Welcome to the next installment of the .NET Nuts & Bolts column. This article covers some creational design patterns and how to implement them using Microsoft .NET. It starts by exploring some of the common patterns and explaining why you should use them, followed by some simple examples. You’ll learn about a number of classes from different namespaces.
Definition of a Design Pattern
A design pattern is a solution for a common problem or issue. Design patterns are often associated with object-oriented programming, but they are not exclusive to it. In fact, even non-computing disciplines have concepts similar to design patterns, which is likely from where the programming community borrowed the concept.
A design pattern does not imply that only one solution to the problem exists, nor is it necessarily the best solution in all cases. Patterns merely provide a best-practice approach to a particular problem, learned from the countless experiences of the programming community. A pattern often has several variations. Each programmer must determine if and when to apply a particular pattern. Often, the programming environment in use influences the pattern choice. Not all programming environments and languages support all design patterns. What may be easy to create in one environment or language may be extremely difficult in another.
Patterns focus on many types of problems. Related patterns are grouped together and assigned a type. This helps programmers identify similar types and it simplifies the process of comparing similar patterns to find the appropriate one(s) to utilize. One such grouping is the creational design patterns: patterns focused on creating instances of objects. A class represents the definition of an object. An instance of an object is where the object/class has been created in memory, which in many languages is commonly done using the new keyword. This process is often referred to simply as instantiation.
Singleton Design Pattern
The singleton design pattern is focused on having one—and only one—instance of an object. It instills encapsulated control of the object from a common place. An example is a directory service. The directory may contain multiple types of entries, but you want only one instance of the actual directory through which all information is accessed and controlled.
Limit an Object to a Single Instance
When thinking about limiting an object to a single instance, the C# keyword static immediately comes to mind. A common misperception is that assigning static to the class will easily solve the problem. In actuality, because static cannot be applied at the class level, the solution is more complex. You must rely on the use of static within the class to create the desired behavior.
The first step is to create a class with a static member field and/or property to contain your internally stored data. The type of data you use dictates the field/property data type. An ArrayList or Hashtable is a common choice because it allows a dynamic number of objects to be stored and manipulated.
Next, prevent the object from being directly created by making all constructors private. This will allow you to restrict creation of all instances through a single method.
Finally, provide a static method for controlling access to your single instance.
Singleton Sample Code
The following sample code depicts how to implement the singleton design pattern in C#. It utilizes a GetInstance() static method to control a reference to the single instance of the class:
using System;namespace CodeGuru.DesignPattern{ /// <summary> /// Class to demonstrate the use of the singleton design pattern. /// </summary> public class SingletonExample { /// <summary>Internal singleton instance</summary> private static SingletonExample _Singleton; /// <summary> /// Constructor to keep the class from being publicly instantiated. /// </summary> private SingletonExample() { } /// <summary> /// Control access to a single instance of the class. /// </summary> /// <returns></returns> public static SingletonExample GetInstance() { if( _Singleton == null ) { _Singleton = new SingletonExample(); } return _Singleton; } /// <summary> /// Use the instance to get some random data. /// </summary> /// <returns>Random data fetched from the instance.</returns> public int GetRandomInstanceData() { Random random = new Random(); return random.Next(); } }}
Revised Singleton with a Controlled Load Sample Code
The above sample works great, as long as what you are trying to control access to is immediately available. What if loading the data from its source took some time? In the directory service example, the data contained within is likely to be thousands of rows of data that will not be instantly accessible. A time lag would occur from when you first tried to access the data to when it was ready for consumption.
You can work around this by adding a couple of status indicators that show whether the object currently is loaded or loading. Then, in the constructor, you call a method to initialize the object depending upon the status of its state indicators. If the object is loaded, no action is required. If the instance is not loaded or is currently being loaded, the method starts the loading process. If the object is loading, it will wait until it is loaded. Locking the class while it is loading allows the instance data to load without getting interrupted:
using System;namespace CodeGuru.DesignPattern{ /// <summary> /// Class to demonstrate the use of the singleton design pattern. /// </summary> public class SingletonExample { /// <summary>Internal singleton instance</summary> private static SingletonExample _Singleton; /// <summary>Indicator if the object has been loaded.</summary> private static bool _IsLoaded = false; /// <summary>Indicator if the object is being loaded.</summary> private static bool _IsLoading = false; /// <summary> /// Constructor to keep the class from being publicly instantiated. /// </summary> private SingletonExample() { this.Initialize(); } /// <summary> /// Control access to a single instance of the class. /// </summary> /// <returns></returns> public static SingletonExample GetInstance() { if( _Singleton == null ) { _Singleton = new SingletonExample(); } return _Singleton; } /// <summary> /// Use the instance to get some random data. /// </summary> /// <returns>Random data fetched from the instance.</returns> public int GetRandomInstanceData() { Random random = new Random(); return random.Next(); } /// <summary> /// Check if the data has been loaded and return the status. /// </summary> /// <returns></returns> private bool Initialize() { if( SingletonExample._IsLoaded ) { // Data has already been loaded return true; } else if( SingletonExample._IsLoading ) { while( SingletonExample._IsLoading ) { // Block the calling thread for 50 milliseconds System.Threading.Thread.CurrentThread.Join(50); } return this.Initialize(); } else { // Load the data this.LoadData(); return this.Initialize(); } } /// <summary> /// Load the data into the instance. /// </summary> private void LoadData() { lock(typeof(SingletonExample)) { SingletonExample._IsLoaded = false; SingletonExample._IsLoading = true; // Do something to load data here.... SingletonExample._IsLoaded = true; SingletonExample._IsLoading = false; } } }}
Factory Design Pattern
The factory design pattern involves having an interface definition for an object and having a class determine the actual creation of a concrete class. The controlling class determines which specific type of class is desired and creates it at runtime. This pattern can be very useful for things such as error logging within an application where the error can be logged to any number of locations (such as a database or file).
An interface dictates the behavior the loggers are to provide and creates a common set of method calls for logging information. All references to loggers within the calling objects would be typed as the logging interface. Rather than create a specific instance of a database or file logger when an error occurs, another controlling class determines which specific type to instantiate and returns it. This allows the logging type to be configurable within the application.
Factory Sample Code
The following sample C# code depicts how to implement the factory design pattern. It is important to note that I chose to use an abstract class for the Logger in place of an interface. The main difference is that using an abstract class allows me to include any additional methods within the Logger class that are common to all of the loggers. This is a technique I find very useful for isolating utility type methods applicable to only a specific type of object and its instances. An interface would not allow this same behavior:
using System;namespace CodeGuru.DesignPattern{ /// <summary> /// Sample abstract class dictate iteration with the logging. /// </summary> public abstract class Logger { public abstract void LogError(Exception exception); public abstract void LogError(string error); } /// <summary> /// Sample class to contain database specific logging. /// </summary> public class DbLogger : Logger { public DbLogger() { } public override void LogError(Exception exception) { // Db specific logging here ... } public override void LogError(string error) { // Db specific logging here ... } } /// <summary> /// Sample class to contain file specific logging. /// </summary> public class FileLogger : Logger { public FileLogger() { } public override void LogError(Exception exception) { // File specific logging here ... } public override void LogError(string error) { // File specific logging here ... } } /// <summary> /// Control creation of concrete instances of Loggers. /// </summary> public class LogFactory { /// <summary> /// Constructor to create the object from being instantiated. /// </summary> private LogFactory() { } /// <summary> /// Create a concrete instance of a logging class based on the input. /// </summary> /// <param name="logType">Type of logger to instantiate.</param> /// <returns>Concreate instance of a Logger.</returns> public static Logger GetLogger(int logType) { if( logType == 1 ) { return new DbLogger(); } else { return new FileLogger(); } } } /// <summary> /// Sample class to use a Logger to log a message. /// </summary> public class Log { private int _LogType; /// <summary>Get or set the type of log to use.</summary> public int LogType { get { return this._LogType; } set { this._LogType = value; this._Logger = LogFactory.GetLogger(value); } } /// <summary>Logger instance to perform the logging.</summary> private Logger _Logger; /// <summary> /// Constructor /// </summary> public Log() { this.LogType = 1; } /// <summary> /// Log an exception. /// </summary> /// <param name="exception">Exception to log.</param> public void LogError(Exception exception) { _Logger.LogError(exception); } /// <summary> /// Log an error message. /// </summary> /// <param name="error">Error message to log.</param> public void LogError(string error) { _Logger.LogError(error); } }}
A number of classes comprise this solution. The first is the abstract class that defines how you’ll access your Logger. The next two classes, DbLogger and FileLogger, are very basic placeholder examples of where the database and file-specific logging (respectively) would be implemented. The fourth class is the LogFactory, which controls the instantiation of concrete instances of the desired Logger based on the requested type. The fifth and final class involved is the Log class, which is a logging controller of sorts. You configure this object as desired to control access to the underlying logging capabilities.
Possible Pattern Enhancements
You now have seen a few examples of creational design patterns, along with some examples of how you can apply them. This article touched on only the tip of the iceberg when it comes to design patterns. There are a couple of additional creational patterns, along with a host of other categories containing numerous design patterns of their own. Consider the following items pertaining to the patterns:
- You can use the ASP.NET cache or application state to implement a singleton pattern as well. The GetInstance() method would check whether the appropriate cache or application setting location exists. If it was already loaded, it would pull from the source. Otherwise, it would load it. This isn’t necessarily preferred over the pattern example, but rather an example of another way to implement it.
- The factory example represents the log type to create (database or file) with an integer. The LogType property on the Log controls which type of Logger is created and utilized for the actual logging. This could just as easily be an enumerated type that represents all allowable types of loggers, or reflection could be used to create an instance of any type of Logger that inherits from the Logger base class.
- Rather than have a specific number or enumeration to represent the logger in the factory design pattern, the desired logging configuration from an application configuration file could use the System.Configuration.ConfigurationSettings.AppSettings() method. This would allow you to dynamically choose which logger to use based on the application configuration and even call loggers contained within another assembly.
Future Columns
The topic of the next column is yet to be determined. If you have something in particular that you would like to see explained here, you could reach me at mstrawmyer@crowechizek.com.
About the Author
Mark Strawmyer (MCSD, MCSE, MCDBA) is a senior architect of .NET applications for large and mid-sized organizations. Mark is a technology leader with Crowe Chizek in Indianapolis, Indiana. He specializes in architecture, design, and development of Microsoft-based solutions. Mark was honored to be named a Microsoft MVP for application development with C#. You can reach Mark at mstrawmyer@crowechizek.com.
