As application development matured as a discipline, design
patterns emerged as solutions for common programming problems. Design patterns
provide a vehicle for experienced developers to share their time-tested
approaches to solving problems faced by every developer day after day. I’ll
explore how you can use design patterns in your development efforts, with a
particular emphasis on the .NET singleton pattern.

Where’s the code?

A design pattern presents a way to tackle and solve a
problem—it doesn’t provide a magic code library that solves all of your issues,
which is a big disappointment to developers who assume they no longer need to
learn code.

Using the singleton pattern

The .NET singleton pattern is one of the best known and
straightforward design patterns in use today. While it can get a bit complex,
the basic premise is simple: allow only one instance of an object to be
created. The concept is applicable in many design scenarios.

Weekly .NET tips in your inbox

TechRepublic’s free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET.

Automatically sign up today!

For example, you may have a counter class that tracks some
aspect of a system—you would only want (or need) one instance of this object to
maintain a valid count. Additionally, you may wish to restrict the number of
child forms opened from a particular form to one. The child forms could utilize
a class (derived from the base form) that allows only one instance of it.

You may be wondering whether you could use a static class or
methods to achieve the same result. Singleton is a good choice if the class
actually needs to be in memory and maintain the state of something. With the
counter example, you may be tempted to use a static global variable, but it
only solves one of the problems: global accessibility. It does nothing to
ensure there is only one instance of a class running at a given time (this may
not be necessary in all situations). The responsibility of having only one
instance of the class should fall on the class itself and not on the user of
the class.

Coding the singleton pattern

When using the singleton pattern, there are several things
to remember:

  • The
    class has a single constructor. It is private and accepts no parameters
    (accepting different parameters could result in different objects). The
    private declaration prevents other classes from instantiating it, which is
    a violation of the pattern. In addition, the private label prevents
    sub-classing. This is necessary since sub-classing allows the derived
    classes to create instances thus more than one instance.
  • The
    class has a static variable that holds a reference to the single class instance.
  • The
    class has a publicly available static method to gain access to the single
    class instance.

The crux of these guidelines is the enforcement of a single
class instance. The C# code in
Listing A defines a class that uses the singleton
pattern. Listing B contains the equivalent VB.NET.

A few notes on the class:

  • The
    constructor is private and therefore inaccessible, so no instances may be
    created with it.
  • The
    public Instance method provides access to the object instance. It returns
    the sole instance of the object via the static variable containing the
  • The
    sealed declaration for the class is overkill. Sealed classes are used to
    restrict the inheritance feature of object-oriented programming. Once a
    class is defined as sealed class, this class cannot be inherited.
  • The
    counter variable is private and accessible via the public get method.
    There will be only one instance of the counter since there is only one
    instance of the class.

There are a few different approaches to coding the singleton
pattern. The previous listing uses a static object for the instance, and it is
always there. This can create overhead if the object is never actually used.
Therefore, you could use the approach in
Listing C.
Listing D contains the equivalent VB.NET.

This second example creates the object only when (and if)
the GetInstance method is called. Therefore, if the object is never utilized,
then it is never created, which will save system resources. It uses a static
flag variable to track object existence.

The first approach is often used to combat thread issues
since only one instance of the object will always exist. Threads can create
problems with the second example, resulting in separate instances in each
thread. You can go further by using locks to control object creation, but we
won’t dive into it in this article. In order to be threadsafe, you should go
with the second approach.


Design patterns are commonly understood concepts that have
been tried, tested, and refined by the development community. The singleton
design pattern is a great approach to providing a single point of object access
in your application. Keep the singleton pattern in mind during upcoming
projects because you may find various scenarios where it is applicable.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.

Miss a column?

Check out the .NET Archive, and catch up on the most recent editions of Tony Patton’s column.