.net – Why singleton class should be sealed

class-designdesign-patternsnetsealedsingleton

I want to know the why a singleton class should be sealed. If we are giving the constructor as private we can prevent the class to be derived right?.. Below i'm pasting few lines from MSDN. Please give me some color on it..

In this strategy, the instance is created the first time any member of the class is referenced. The common language runtime takes care of the variable initialization. The class is marked sealed to prevent derivation, which could add instances. For a discussion of the pros and cons of marking a class sealed, see [Sells03]. In addition, the variable is marked readonly, which means that it can be assigned only during static initialization (which is shown here) or in a class constructor.

http://msdn.microsoft.com/en-us/library/ff650316.aspx

Best Answer

If we are giving the constructor as private we can prevent the class to be derived right?

Not quite:

public class NotReallySingleton
{
    private NotReallySingleton() {}

    public class CursesFoiledAgain : NotReallySingleton
    {
    }
}

...

NotReallySingleton x = new CursesFoiledAgain();
NotReallySingleton y = new CursesFoiledAgain();

This works because private access is limited to the program text of the type, including nested types. So CursesFoiledAgain has access to the private constructor of NotReallySingleton.

But even leaving this aside, if your intention is that no-one can derive from the class, why would you not want to signal that intention as clearly as possible, via sealed?

Related Solutions

C++ – Singleton: How should it be used

Answer:

Use a Singleton if:

You need to have one and only one object of a type in system

Do not use a Singleton if:

You want to save memory
You want to try something new
You want to show off how much you know
Because everyone else is doing it (See cargo cult programmer in wikipedia)
In user interface widgets
It is supposed to be a cache
In strings
In Sessions
I can go all day long

How to create the best singleton:

The smaller, the better. I am a minimalist
Make sure it is thread safe
Make sure it is never null
Make sure it is created only once
Lazy or system initialization? Up to your requirements
Sometimes the OS or the JVM creates singletons for you (e.g. in Java every class definition is a singleton)
Provide a destructor or somehow figure out how to dispose resources
Use little memory

C# – Should ‘using’ directives be inside or outside the namespace

There is actually a (subtle) difference between the two. Imagine you have the following code in File1.cs:

// File1.cs
using System;
namespace Outer.Inner
{
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Now imagine that someone adds another file (File2.cs) to the project that looks like this:

// File2.cs
namespace Outer
{
    class Math
    {
    }
}

The compiler searches Outer before looking at those using directives outside the namespace, so it finds Outer.Math instead of System.Math. Unfortunately (or perhaps fortunately?), Outer.Math has no PI member, so File1 is now broken.

This changes if you put the using inside your namespace declaration, as follows:

// File1b.cs
namespace Outer.Inner
{
    using System;
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

Now the compiler searches System before searching Outer, finds System.Math, and all is well.

Some would argue that Math might be a bad name for a user-defined class, since there's already one in System; the point here is just that there is a difference, and it affects the maintainability of your code.

It's also interesting to note what happens if Foo is in namespace Outer, rather than Outer.Inner. In that case, adding Outer.Math in File2 breaks File1 regardless of where the using goes. This implies that the compiler searches the innermost enclosing namespace before it looks at any using directive.

Best Answer

Related Solutions

C++ – Singleton: How should it be used

C# – Should ‘using’ directives be inside or outside the namespace

Related Topic