Nested Singleton Class

Question

Is it possible to nest a singleton class inside a non-singleton class in C#, and if so, are there any restrictions to the life-cycle of the singleton in this case?

public class NonSingletonClass
{
  public NonSingletonClass()
  {
    // Initialize some stuff.
  }

  // Put some methods here.

  public class SingletonClass
  {
    // Singleton construction goes here.

    // Put some methods here.
  }
}

In the design of my application, this makes sense, but I need to know of any potential gotchas before I actually implement this.

EDIT: Specifically, I have a job host that executes tasks based on a timer. The NonSingletonClass in this case is an instantiation of a task. The SingletonClass is a repository of data that is used by NonSingletonClass, but can be modified from outside of NonSingletonClass. SingletonClass exists to ensure that even if there are multiple NonSingletonClass instances, there will still be only one set of instructions and data for all of them.

Answer 1

I believe you are looking for a monostate pattern

this link is a good description of this and offers contrats with a singleton pattern monostate pattern

Answer 2

Yes, a singleton can live entirely comfortably within a non-singleton.

The lifecycle of the nested class is entirely independent on the lifecycle of the outer class. There's very little difference between a nested class and a non-nested class in C#. (There are some differences - the nested class has access to private members of the outer class, and extension methods have to be in a non-nested static class, for example - but it doesn't affect the lifecycle.

Did you have a specific concern?

Answer 3

I guess my first question is could you give us more specifics considering you stated "the the design of my application this makes sense". Abstract factory and builder are just some patters that use the singleton classes. Are you storing some sort of global data to be used within NonSingletonClass.

Answer 4

I don't think that there are any problems with a nested singleton considering that neither class holds a reference to the other. Considering that you say that the singleton provides mutable data storage for several instances, I think your potential problems are going to be concurrency related.

These apply only if multi-thread access is allowed, that is, first we have to ensure the appropriate locks are in place so that the singleton is always in a valid state. And second, if the singleton state is changing and objects are accessing in non-deterministic order, the results will not be predictable (i.e. a race condition).

If concurrency is not an issue with the application, I find the use of private nested classes to be an excellent way of hiding implementation details and ensuring each object has only one role.