Posts Tagged ‘design patterns’

The importance of the GoF Design Patterns book.

// July 30th, 2007 // 4 Comments » // design patterns, software development

I have been reading a lot of discussions regarding the importance of the “Design Patterns: Elements of Reusable Object-Oriented Software” book written by the GoF. Many people seem to criticize the book by saying that the book no longer relevant. I completely disagree with this view. The GoF Design Patterns book is a classic and will always be a classic.

I have been reading a lot about it and the view I have regarding this book, is that it is meant to show you how to design software solutions of a problem. Many people use it wrongly as a cookbook, where they just copy the examples and apply them to their solution, but the examples displayed in the GoF Design Patterns book are aimed at specific problems. this doesn’t mean you cannot use the singleton pattern in your software; of course you can, but the implementation they provided may not be the best fit for your solution.

It also provided us with a language for communicating all these complex patterns, where as before it was very difficult to communicate. Just image explaining to somebody the Observer Pattern without using the reference of GoF Design Patterns book; add the language barrier, now that we have so many people from around the world in the office. It would have been very difficult.

I think the GoF Design Patterns book is very important and useful today, as it was when it was published. It will remain that way for a long time.

Implementing the Observer Pattern

// November 2nd, 2006 // 2 Comments » // .net, Algorithms, design patterns, Language Idioms, software development

Two months ago, I posted about how to Communicate between C# classes, which actually displays an Observer pattern in a C# way, using delegates and events. After finishing my post, I felt like something was missing, so this is my attempt to fill in the blanks.

The Observer Pattern
Also know as the Publisher/Subscriber pattern is generally used to monitor the state of an instance or object in an application. The idea behind the Observer pattern is to communicate the state of one class instance to another, in another words communicating between each other (at least unidirectionally).

There are several implementations for this pattern, especially for C#. Even thought the Observer pattern is implemented implicitly in C# with delegates and events, I’m going to display other two solutions which I consider interesting.

The Observer pattern has two actors involved, the Subject (which is going to be observed) and the Observer. There’s actually no way that I know of which doesn’t impose a penalty on performance, where the Observer is actually monitoring the Subject. this pattern refers only to the Subject notifying the Observers his own changes, considering of course that the Subject does know about any changes it may have.

So the idea resides on the fact that the Subject notifies its observes about any changes there may be. If there are any changes, once the Observer is notified, it can decide to something with the message or just discard it.

The idea of course of an Observer is something that observes without the Subject being notified, but in this case is different. That is why people always get confused with the Observer pattern, most of them believe that the Observer obtains information from the Subject without the it knowing. Which can actually be really useful. But this is not the case. In this case the Subject notifies the Observer (So maybe it should be call the Notification pattern).

Anyways, this pattern can be used for many different situations, and I don’t intend to cover all of them, it is actually impossible. But this pattern is used a lot in Event Listeners and Event handlers throughout Frameworks, especially Java and C#.

When a button in a form is clicked, then an event is fired, and the event handlers or listeners handle event.In this case the Subject is represented by the Form button which is part of the View in an MVC pattern, and the Observer is the actual controller. Most frameworks now, have the View and Controller in the same class so this would not count as unilateral object communication. But in my previous post it is.

Let’s think about this for a moment. We have a Form which contains a ProgressBar, and the progress value represents the progress of a very long process that is in the Model of the application. Let’s call the Form Myform; and the Model MyModel. So MyModel is doing a very long process, and it notifies MyForm of the progress each time it advances.

This would make MyModel the Subject and MyForm the Observer. MyForm is being notified for all changes in progress made by MyModel. There can be several types of notifications or events; in this case, the notification is related to the progress of MyModel, but then MyModel could also notify all Observers about the estimated ending time of the lengthy process.

Let’s look at some Implementations:

· Highly Coupled Implementation
This implementation is the simplest of all, and it only responds to the pattern policy, not taking into consideration the coupling between classes.

First we have the Observer Interface:

using System;

namespace ObserverPattern
{
    /// <summary>
    /// Interface that represents the observer in the Observer pattern.
    /// </summary>
    public interface IObserver
    {
        /// <summary>
        /// Triggers an update in the observer class.
        /// </summary>
        /// <param name="subject">Object reference of the subject updating.</param>
        void Update(Subject subject);
    }
}

As you can see in the code, the interface for all observers has a method that is called update. This method is called when the Subject object has notified its Observers.

Next we examine the Subject implementation:

using System;
using System.Collections;

namespace ObserverPattern
{
    /// <summary>
    /// Class that represents the abstract subject of an observer pattern.
    /// </summary>
    public abstract class Subject
    {
        /// <summary>
        /// List of registered observers.
        /// </summary>
        private ArrayList observers = new ArrayList(); 

        /// <summary>
        /// Default Constructor.
        /// </summary>
        public Subject()
        {
        }
        
        /// <summary>
        /// Adds an observer to the list of registered observers
        /// </summary>
        /// <param name="observer">Observer to add</param>
        public void AddObserver(IObserver observer)
        {
            observers.Add(observer);
        }
        
        /// <summary>
        /// Removes an observer to the list of registered observers.
        /// </summary>
        /// <param name="observer">Observer to remove</param>
        public void RemoveObserver(IObserver observer)
        {
            observers.Remove(observer);
        }
        
        /// <summary>
        /// Notifies all registered observers.
        /// </summary>
        public void Notify()
        {
            foreach(IObserver observer in observers) {
                observer.Update(this);
            }
        }
    }
}

As you it can be seen in the code, this abstract class is a little more complex than the observer interface. The Subject is based on a list of Observers which can be added or removed from the list, and which are notified as required. The method Notify() is the one that communicates with the observes through their Update() method.

Since the Subject class is abstract, it cannot be instantiated, it can only be inherited, so we need an implementation class for the Subject, let’s call it MySbuject:

using System;
using System.Collections;

namespace ObserverPattern
{
    /// <summary>
    /// Class that represents the subject of an observer pattern.
    /// </summary>
    public abstract class MySubject : Subject
    {
        /// <summary>
        /// Default Constructor.
        /// </summary>
        public MySubject() : base()
        {
        }
       
        /// <summary>
        /// Notifies all observers.
        /// </summary>
        public void NotifyObservers()
        {
            this.Notify(this);
        }
    }
}

MySbuject is a simple class which implements the Subject abstract class, and which notifies all Observers through the NotifyObservers() method.

Now let’s look at the MyObserver implementation of IObserver:

using System;

namespace ObserverPattern
{
    /// <summary>
    /// Class that represents the observer in the Observer pattern.
    /// </summary>
    public class MyObserver : IObserver
    {
        /// <summary>
        /// Triggers an update in the observer class.
        /// </summary>
        /// <param name="subject">Object reference of the subject updating.</param>
        public void Update(Subject subject)
        {
            // Do some work.....
        }
    }
}

The updateMethod() is the one that actually handles the notification from the Subject, and here it decides whether to do something with the notification or just discard it; that all depends on the notification or event type.

Advantages
The Advantages of this implementation is that is very simple to grasp. It has no other complexities than that of the pattern itself.

Disadvantages
This implementation has a lot of disadvantages; first of all it has a really tight coupling between the classes, especially the Subject abstract class and MySubject class. I have never been a supporter of Inheritance. I know it is some times useful, even though I can’t think of one now, but I still prefer composition, or interfaces.

Another disadvantage is that the implementation is lengthy. There are at least 4 classes involved, which I consider not to be simple enough.

· Less Coupled Implementation
Let’s tackle on disadvantage at a time. Let’s decouple the classes a little bit.

Since the Subject abstract class contains implementation for the methods Add, Remove and Notify; and they are all implemented in the same way for all Subjects, there is no need to implement the process of Adding, Removing and Notifying observers in all childs classes by building an implementation. Let’s use Interfaces and Composition.

In order to do this, we need to create an interface for all Subjects which we will call ISubject:

using System;
using System.Collections;

namespace ObserverPattern
{
    /// <summary>
    /// Interface that represents the subject of an observer pattern.
    /// </summary>
    public interface ISubject
    {    
        /// <summary>
        /// Adds an observer to the list of registered observers
        /// </summary>
        /// <param name="observer">Observer to add</param>
        void Add(IObserver observer);
        
        /// <summary>
        /// Removes an observer to the list of registered observers.
        /// </summary>
        /// <param name="observer">Observer to remove</param>
        void Remove(IObserver observer);
        
        /// <summary>
        /// Notifies all registered observers.
        /// </summary>
        void Notify();
    }
}

The interface, as it can be seen in the code, only contains the methods that were mentioned in the Subject abstract class but without implementation. this interface helps decouple the IObserver interface too, and it would change in the following way:

using System;

namespace ObserverPattern
{
    /// <summary>
    /// Interface that represents the observer in the Observer pattern.
    /// </summary>
    public interface IObserver
    {
        /// <summary>
        /// Triggers an update in the observer class.
        /// </summary>
        /// <param name="subject">Object reference of the subject updating.</param>
        void Update(ISubject subject);
    }
}

As you can see in the code, now the IObserver interface uses ISubject interface instead of an Subject abstract class, which made it dependent on the implementation of the Subject; now the interface is free from implementation.

Now we have a problem. If all subject implement this interface (ISubject), they are all going to re-invent the wheel while implementing Add, Remove and Notify methods for all Subjects. We can actually fix this with composition.

Let’s create a new class named SubjectHelper, which has the following implementation:

using System;
using System.Collections;

namespace ObserverPattern
{
    /// <summary>
    /// Class that represents the subject helper of an observer pattern.
    /// </summary>
    /// <remarks>
    /// This class is created to lesser the coupling between the IObserver interface
    /// and the abstract Subject class. Splitting the Subject abstract class into an 
    /// ISubject interface and a SubjectHelper class.
    /// Then the helper is only a provider of notification services, which any class 
    /// can use without  creating tightly coupled classes.
    /// </remarks>
    public class SubjectHelper : ISubject
    {
        /// <summary>
        /// List of registered observers.
        /// </summary>
        private ArrayList observers = new ArrayList(); 

        /// <summary>
        /// Default Constructor.
        /// </summary>
        public SubjectHelper()
        {
        }
        
        /// <summary>
        /// Adds an observer to the list of registered observers
        /// </summary>
        /// <param name="observer">Observer to add</param>
        public void Add(IObserver observer)
        {
            observers.Add(observer);
        }
        
        /// <summary>
        /// Removes an observer to the list of registered observers.
        /// </summary>
        /// <param name="observer">Observer to remove</param>
        public void Remove(IObserver observer)
        {
            observers.Remove(observer);
        }
        
        /// <summary>
        /// Notifies all registered observers.
        /// </summary>
        /// <param name="realSubject">Real subject calling the helper.</param>
        public void Notify(object realSubject)
        {
            foreach(IObserver observer in observers) {
                observer.Update(realSubject);
            }
        }
    }
}

As you can see, the SubjectHelper class includes all the implementation for the methods Add, remove and Notify, just like it used to in the Subject abstract class. It is the same implementation, except for the Notify method, which includes a parameter for the real subject, or the real sender.

Let me show you how the SubjectHelper would be used, in the implementation of MySubject class:

using System;
using System.Collections;

namespace ObserverPattern
{
    /// <summary>
    /// Class that represents the subject of an observer pattern.
    /// </summary>
    public abstract class MySubject
    {
        private SubjectHelper subjectHelper = new SubjectHelper();

        /// <summary>
        /// Default Constructor.
        /// </summary>
        public MySubject() : base()
        {
        }

        /// <summary>
        /// Adds an observer to the list of registered observers
        /// </summary>
        /// <param name="observer">Observer to add</param>
        public void AddObserver(IObserver observer)
        {
            this.subjectHelper.Add(observer);
        }
        
        /// <summary>
        /// Removes an observer to the list of registered observers.
        /// </summary>
        /// <param name="observer">Observer to remove</param>
        public void RemoveObserver(IObserver observer)
        {
            this.subjectHelper.Remove(observer);
        }        
       
        /// <summary>
        /// Notifies all observers.
        /// </summary>
        public void NotifyObservers()
        {
            this.subjectHelper.Notify(this);
        }
    }
}

Composition is a really great design artifact. the idea behind the MySubject class is that it DOESN’T inherit ISubject interface, but it wraps around the SubjectHelper; leaving out all problems related to inheritance. This is what composition is all about.

Advantages
This approach reduces the coupling enough to be a flexible solution. It can be reused without any problems of scalability.

Disadvantages
It is a bit more complex than the other approach, and it is a lot bigger in number of classes. The other approach had 4 classes involved, this approach has 5.

· .Net Implementation
C# is a piece of beauty. The less coupled approach is a great implementation, don’t get me wrong, but it is still a lot of code. Well don’t worry, for C# we have a concept called ‘Delegates’ which simplifies the Observer pattern a lot.

Let’s see the implementation of the observer pattern using Delegates, shown below is the Subject’s implementation:

using System;

namespace DotNetObserverPattern
{
    /// <summary>
    /// Class that represents a subject in the observer pattern.
    /// </summary>
    public class MySubject
    {        
        /// <summary>
        /// Delegate that represents a notify handler.
        /// </summary>
        public delegate void NotifyHandler(object Subject);

        /// <summary>
        /// Notify Event Handler.
        /// </summary>
        public event NotifyHandler NotifyEvent;

        /// <summary>
        /// Default Constructor.
        /// </summary>
        public MySubject()
        {
        }
        
        /// <summary>
        /// Notifies all registered observers.
        /// </summary>
        public void Notify()
        {
            if(null != NotifyEvent) {
                this.NotifyEvent(this);
            }
        }        
    }
}

As you can see there is no need for an interface ISubject or a SubjectHelper. Everything is already done with the delegates publish/subscribe mechanism. It is simply a piece of beauty.

Now let’s see the Observer implementation:

using System;

namespace DotNetObserverPattern
{
    /// <summary>
    /// Class that represents an observer in the observer pattern.
    /// </summary>
    public class MyObserver
    {        
        /// <summary>
        /// Default Constructor.
        /// </summary>
        public MyObserver()
        {
        }

        /// <summary>
        /// Triggers an update in the observer class.
        /// </summary>
        /// <param name="subject">Object reference of the subject updating.</param>
        public void Update(Object subject)
        {
            if(subject is MySubject) {
                // Do some work....
            }
        }
    }
}

Also very simple.

Advantages
It is very simple. It is not tightly coupled. It just takes a few lines of code.

Disadvantages
None that I could think of at the time of witting this post.

· Conclusion
The three implementations work and they follow the Observer pattern policy. Each one has its advantages and disadvantages. I obviously use the .Net implementation, since it is a lot simpler and more robust.

Implementing a Singleton in C# Reloaded.

// June 9th, 2006 // Comments Off on Implementing a Singleton in C# Reloaded. // .net, design patterns, software development

Thanks to an anonymous friend, I began reading a really interesting document, which exposes some holes in my design implementation for a Singleton.

Jon shows five code blocks, from which the first four are similar to the ones I displayed in my original post. I found several differences which I will explain in just a moment. The fifth code block, seems pretty elegant and interesting; but I think it is not always required. It is too much hassle for me.

But the fourth implementation seems a lot like mine, with a few interesting differences which I should have noticed before. First of all, Jon prevents inheritance explicity with the ‘sealed’ keyword. When I developed my version, I was aware that if the constructor is private and unique, then there could be no subclassing. But as he pointed out, using the ‘sealed’ keyword provides the JIT a way to optimize the code. This I didn’t know. I guess I need to focus a little more on optimization.

The other main difference is the use of the ‘readonly’ keyword while declaring the private static instance. The ‘readonly’ keyword is used when you want to declare a constant variable with the difference that you don’t know the value at compile time. This means that if you need a variable whose value is only determined at runtime, using the readonly, when that variable gets its value, it can never change. It is like a const with one chance to stablish a value at runtime.

Using the ‘readonly’ keyword reinforces the pattern policy: To only have one instance. The way I see it, there is no way that you can change the value of instance in my implementation, even without the ‘readonly’ keyword. But hey, I’m not omnipotent, so I better make sure there is no way that can be done. The ‘reaonly’ keyword then is a great help maintaining the pattern true to its objective. This is what I call Defensive programming.

Using the ‘sealed’ and ‘readonly’ keyword, I’m making sure that pattern stays uncorrupted. It is a defensive approach, and it works.

Ok, after all that babble, here is the final code for the Singleton Implementation in C# (which is in fact the Fourth escenario in Jon’s document) :

/// <summary>
/// Class that represents an implementation for the Singleton Pattern in C#
/// </summary>
public sealed class MySingletonClass
{   
    private static readonly MySingletonClass instance = new MyClassSingletonClass();
    
    /// <summary>
    /// Private constructor, required for singleton design pattern.
    /// </summary>
    private MySingletonClass()
    {
 	/* Do contruction work.*/
    }

    /// <summary>
    /// Provides access to the singleton class returning 
    /// a unique instance of the MySingletonClass object.
    /// </summary>
    public static MySingletonClass Instance
    {
        get {            
            return instance;
        }
    }
}

Implementing a Singleton in C#

// June 6th, 2006 // 9 Comments » // .net, design patterns, Language Idioms, software development

A few years back, when I got into Design Patterns, I got very frustrated with the fact that most of the information that I could find was either focused on C++ or Java. I am a hardcore C++ fan, but I got pretty interested in C#, so I wanted to apply that knowledge to it. I think the easiest pattern there is to implement is the Singleton. I love the Singleton pattern, becuase it is so simple, but so powerful and above all useful.

The intent of the singleton pattern according to the ‘Gang of Four’ (Gamma et Al., 1995) is: “Ensure a class only has one instance, and provide a global point of access to it”.

What this means is that the Singleton pattern makes sure that a certain class has only one instance and that can be accesible gloablly.

My solution for the Singleton pattern is shown below:

/// <summary>
/// Class that represents an implementation for the Singleton Pattern in C#
/// </summary>
public class MySingletonClass
{   
    private static MySingletonClass instance = new MySingletonClass();
    
    /// <summary>
    /// Private constructor, required for singleton design pattern.
    /// </summary>
    private MySingletonClass()
    {
        /* Do contruction work.*/
    }

    /// <summary>
    /// Provides access to the singleton class returning a unique instance 
    /// of the MySingletonClass object.
    /// </summary>
    public static MySingletonClass Instance
    {
        get {
            return instance;
        }
    }
}

You would then access the class like this:

MySingletonClass object = MySingletonClass.Instance;

You can see that the constructor is private, making it impossible for someone to instantiate the class several times. There is only one instance of the class and it is constructued inside the class itself.

There are several ways to implement a Singleton pattern. This solution is the one I think it is best fitted for the job; it is thread safe, simple yet powerful. And most important, it works.

I have seen some implementations like this one:

/// <summary>
/// Class that represents an implementation for the Singleton Pattern in C#
/// </summary>
public class MySingletonClass
{   
    private static MySingletonClass instance = null;
    
    /// <summary>
    /// Private constructor, required for singleton design pattern.
    /// </summary>
    private MySingletonClass()
    {
        /* Do contruction work.*/
    }

    /// <summary>
    /// Provides access to the singleton class returning a unique instance 
    /// of the MySingletonClass object.
    /// </summary>
    public static MySingletonClass Instance
    {
        get {
            if(null == instance) {
                instance = new MySingletonClass();
            }
            return instance;
        }
    }
}

This is called ‘Lazy Initialization’. I actually believe that this implementation is not good enough and it has a performance issue, specially in big classes. But the thing I don’t like the most about this implementation, is that it is not thread safe. Why ? You ask. Well when a class in one thread calls the Instance property at the same time that another one in a different thread, you can create a potential memory leak, and thus breaking the Singleton pattern premise: ‘Only one instance’.

But don’t worry, there is also another implementation that fixes this one, with ‘Double-Checked locking’:

/// <summary>
/// Class that represents an implementation for the Singleton Pattern in C#
/// </summary>
public class MySingletonClass
{   
    private static MySingletonClass instance = null;
    static readonly object padlock = new object();
    
    /// <summary>
    /// Private constructor, required for singleton design pattern.
    /// </summary>
    private MySingletonClass()
    {
 	/* Do contruction work.*/
    }

    /// <summary>
    /// Provides access to the singleton class returning a unique instance 
    /// of the MySingletonClass object.
    /// </summary>
    public static MySingletonClass Instance
    {
        get {
            if(null == instance) {
                lock(padlock) {
                    if(null == instance) {
                        instance = new MySingletonClass();
                    }
                    return instance;
                }
            }
        }
    }
}

The difference here resides in the double checking lock to ensure thread safety. This solution, as I later found out, doesn’t actually work. There is no way to ensure that there will be only one instance, even with double lock checking.

As a conclusion, the solution posted at the beggining is the best implementation for the job, at least for C#. I have talked with some hard core Java developers, and it seems this implementation also works in Java. I have not researched it enough to make sure it works. But in C# it does work.