Is my singleton design less elegant than it should be? What's the best practice?

Question

I'm currently building a tool for my game engine using WPF. The tool is project-centric (think Visual Studio, XCode, etc.) and allows the user to edit one project at a time.

Currently, my implementation hosts a singleton instance of the project class, ArchitectProject. This is available to all other components as a property on the singleton class. I feel like this implementation is a bit of a hack and not as neat, simple or elegant as it could or should be.

The ProjectManager class, a singleton class within the host application, provides global access to a Project property. Various other properties and methods are exposed, mostly supersets of versions in the Project class but using ProjectManager properties for efficiency.

This feels really, really wrong to me. First and foremost, the static constructor initializes a new Project instance from the start so that WPF doesn't complain about null references when setting up the data binding. There are multiple controls and other components that require access to the current project instance, especially those that are data bound to its properties. Further complicating the data-binding situation is that whenever a property value is replaced with a different instance (e.g., loading an existing project, creating a new one), all WPF data bindings are lost, so additional events and other extra crap are required to ensure each control's data bindings persist properly.

Secondly, the result of making the current Project instance globally accessible is a bunch of related hackery to get the implementation to work properly. Everything in my un-professional gut is telling me I'm doing more work than I need to, and I'm doing it completely wrong from the start.

I suppose my question, at last, is how should I go about implementing a globally-accessible property within my app? I've always liked the notion of programming everything as though you're writing an API. If a developer wanted to hook into my app, the required hacks and extra steps to get everything working would not be immediately apparent, and that screams poor design to me.

Ideas?

Answer 1

The singleton pattern is regarded by many as an anti-pattern. The standard answer is almost always to use (constructor) dependency injection (DI). You can use a good DI container to help you construct all the objects in your graph. I personally use the on from the Castle project, but many alternatives exist.

Answer 2

Without knowing more detail about your application, I would start from trying to introduce Dependency Injection instead of your singleton. You can still have one project at a time, but usually you will find that it will be easier to handle initialization and certain events if you explicitly specify dependencies using constructor arguments. (probably it will not fix all your problems though)

Answer 3

My way to implement singelton:

class SomeClass
{

   private static SomeClass instance;

   private SomeClass() {}

   public static SomeClass SingelInstance
   {
      get 
      {
          if(instance == null)
             instance = new SomeClass();
          return instance;
      }
   }
}