coders corner

By using the Singleton design pattern you ensure that a class has only one instance. The instance operation is provided by the class itself. So it maintains its own unique instance.

The .NET framework offers a very simple and thread-safe way to create a Singleton. The following source code shows an according example, how to create a singleton instance for logging purposes.

At first we define a interface.

public interface ILogger
{
    void Log(string message);
}

Second we can implement the Singleton object. The class instance is provided by a property which returns a read only object. The .NET framework ensures a thread-safe and lazy creation of the class instance.

public class Logger : ILogger
{
    private static readonly Logger _instance = new Logger();

    private Logger()
    {
    }
           
    public static Logger Instince
    {
        get
        {
            return _instance;
        }
    }            

    public void Log(string message)
    {
        throw new NotImplementedException();
    }        
}

And the last code example shows how to use the Singleton within an demo application.

static void Main(string[] args)
{
    ILogger logger;

    logger = Logger.Instince;

    logger.Log("foo");
}

The idea of the Proxy design pattern is to provide a substitute for another object were the substitute controls the access to the other project. So there is one real subject with a given interface, for example an object to access a database. And there is a proxy which maintains a reference to this real subject. They both implement the same interface. So the proxy can be used as substitute of the real subject. Often the client does not even know that he uses a proxy.

The proxy controls the access to the real subject and will be responsible for additional tasks, for example creation or deleting of the real subject. The proxy may add some new functionality for example logging, caching, queuing, remote execution or access control.

The following example shows a possible implementation of the Proxy design pattern. Within the example we want to create a class which sends a message to one or some remote listeners. Sending the message may take a while. Therefore the send method will block the client or the client hast to implement asynchronous method calls. Therefore we want to provide a proxy which is responsible for queuing and sending messages. The proxy shall offer the same functionality like the real message provider extended with a queuing mechanism and asynchronous execution of the remote data transfer.

At first we will define the interface for the message channel.

public interface IMessageChannel
{
    void SendMessage(string message);
}

Now we will implement an according class. To simulate the slow remote execution we add a timeout of one second.

public class MessageChannel : IMessageChannel
{
    public void SendMessage(string message)
    {
        Thread.Sleep(TimeSpan.FromSeconds(1));
    }
}

At next we can create the queued message channel which is a proxy of the real message channel. Therefore it holds an instance of the real object and it implements the same interface. To keep it simple we don’t implement the parallel task which executes the sending process. Instead we just add a DoWork method as example of the content of the parallel task.

public class QueuedMessageChannel : IMessageChannel
{
    Queue<string> _messages = new Queue<string>();
    IMessageChannel _messageChannel = new MessageChannel();

    public void SendMessage(string message)
    {
        _messages.Enqueue(message);
    }

    /// <summary>
    /// send the messages
    /// TODO: this must be executed as loop inside a parallel task
    /// </summary>
    private void DoWork()
    {
        string message;

        if (_messages.Count > 0)
        {
            message = _messages.Dequeue();
            _messageChannel.SendMessage(message);
        }
    }
}

Within a console application we can new use the proxy. In this example the client creates the proxy explicitly. If you use a factory instead, the console application will not even know whether it uses a proxy or not. But on execution of the send method you will see the difference as the proxy method will return immediately.

static void Main(string[] args)
{
    IMessageChannel messageChannel;

    messageChannel = new QueuedMessageChannel();

    messageChannel.SendMessage("abc");
    Console.WriteLine("Message was send");

    messageChannel.SendMessage("abc");
    Console.WriteLine("Message was send");

    messageChannel.SendMessage("abc");
    Console.WriteLine("Message was send");

    Console.ReadKey();
}

The Observer design pattern is used when you want to define a one-to-many dependency between objects. In case one object changes its state, all its dependents are notified and updated automatically.

In this design pattern you have two participants. The first one is the observable object, which knows his observers and provides an interface for attaching, detaching and notifying observer objects. The second participant or group of participants is the objects which want to be informed. These observer objects will implement a notification interface which is called by the observable object.

Following I want to show a simple implementation if this design pattern which is not thread-safe. In our example we want to create database connection which has status information. To keep it simple the status information is a string only.  Furthermore we want to create a user interface which shall show the database connection status within the main view and within a status bar. Therefore we have an observable object: the database connection, and several observers: the views.

The notification between the participants is done by events. So we start with an EventArgs class and an interface for the observer classes which contain the event receiver definition.

public class StatusChangedEventArgs : EventArgs
{
    public string Status { get; set; }        
}

public interface IStatusObserver
{
    void StatusChanged(object sender, StatusChangedEventArgs e);
}

At next we can implement a base class for the observable database connection class. As we implement it as abstract base class it can be reused for other observable classes to.

public abstract class StatusObservable
{
    private event EventHandler<StatusChangedEventArgs> _statusChanged;

    public void AttachObserver(IStatusObserver observer)
    {
        _statusChanged += observer.StatusChanged;
    }

    public void DetachObserver(IStatusObserver observer)
    {
        _statusChanged -= observer.StatusChanged;
    }
        
    public void NotifyAllObserver(StatusChangedEventArgs e)
    {
        if (_statusChanged != null)
        {
            _statusChanged(this, e);
        }
    }
}

Based on the observable class we will implement the database connection class. It contains two template methods to connect and disconnect the database. These methods will execute a status change which will trigger the observer notification process.

public class DatabaseConnection : StatusObservable
{
    public void Connect()
    {
        //todo: connect to database

        //change status            
        ChangeStatus("connected");
    }

    public void Disconnect()
    {
        //todo: disconnect from database

        //change status            
        ChangeStatus("disconnected");
    }

    private void ChangeStatus(string status)
    {
        NotifyAllObserver(new StatusChangedEventArgs() { Status = status });
    }
}

Now we can create the two view classes which will observe the database connection. To keep it simple these classes contain the interface implementation only and write the received status update to the console.

public class MainView : IStatusObserver
{
    public void StatusChanged(object sender, StatusChangedEventArgs e)
    {
        Console.WriteLine("MainView - StatusChanged received - new status: " + e.Status);
    }
}

public class StatusBar : IStatusObserver
{
    public void StatusChanged(object sender, StatusChangedEventArgs e)
    {
        Console.WriteLine("StatusBar - StatusChanged received - new status: " + e.Status);
    }
}

To test the implementation we can create a little console application. Within this application we will attach the observers to the observable database connection and execute some methods of this class. The according notifications will be send and shown as output in the console. Before the application gets closed, the observers will be detached from the observable class.

static void Main(string[] args)
{
    //create objects
    DatabaseConnection databaseConnection = new DatabaseConnection();
    MainView mainView = new MainView();
    StatusBar statusBar = new StatusBar();

    //attach observer
    databaseConnection.AttachObserver(mainView);
    databaseConnection.AttachObserver(statusBar);

    //change status in observable object
    databaseConnection.Connect();
    databaseConnection.Disconnect();

    //detach observer
    databaseConnection.DetachObserver(mainView);
    databaseConnection.DetachObserver(statusBar);

    Console.ReadKey();
}