1

Some time ago I learned of the Singleton implementation that only permits a single instance of a class object by hiding the class initializer and using a private static reference of the object within itself, and a public GETTER that references that private reference - 

public class Foo : IDisposable{
    private static Foo _Instance;
    public static Foo Instance{ get{ return Foo._Instance ?? new Foo(); }
    private Foo(){ Foo._Instance = this; }
    public void Dispose(){ Foo._Instance = null; }
}

I love this quite a lot - it is especially nice for windows that I want accessible application wide.

One thing that I would really like is to be able to implement a generic sort of Singleton Window class upon which a real window could be built and then accessed like this - Is this possible? My thinking was something like - 

public class SingletonWindow : Window {
    private static SingletonWindow _Instance;
    public static SingletonWindow Instance{ get{ return SingletonWindow._Instance ?? new SingletonWindow(); } }
    private SingletonWindow(){ SingletonWindow._Instance = this; }
    private sealed override void OnClosed(EventArgs E){ SingletonWindow._Instance = null; }
}

But... something inside me that I can't quite voice tells me that this will absolutely positively fail miserably. Can someone tell me why this would fail (if, indeed it will fail), if it is possible to achieve what I am attempting to achieve here, and how I might go about doing so if it is possible?

Will
  • 3,413
  • 7
  • 50
  • 107
  • 1
    If you want to have windows that are used application wide, create them as properties of your App class. No need for a Singleton, which is an overrated pattern anyway. You may want to read the [discussion here](http://stackoverflow.com/q/137975/1136211). – Clemens Apr 11 '15 at 19:06
  • I broadly agree with @Clemens. My answer shows how it _could_ be done, rather than how it _should_ be done. – christophano Apr 11 '15 at 19:10
  • @Clemens - You say to use any window application wide, it would be best to use it a as a property of the app class - so; in the case of my XAML/WPF project, in the App.cs class I would just create a global property referencing an instance of these objects? I'm sorry; I don't understand why going 'App.Window' is better than going 'Foo.Instance' (Please forgive my complete and total ignorance on the subject; I'm not that eloquent of a coder - more like a monkey who somehow became smart enough to use a hammer to bang out code that works most of the time)... – Will Apr 11 '15 at 19:27
  • You would get the App *instance* by `(App)System.Windows.Application.Current`, so no need for static properties. – Clemens Apr 11 '15 at 19:29

1 Answers1

2

Personally, I'm not a fan of singletons. That said, if you want a generic class, make it a generic class. You will have to have a static constructor on your derived class that will provide a route to the private constructor to your generic class, but that's about it.

public abstract class Singleton<T> where T : Window, Singleton<T>
{
    protected static Func<T> create;
    private static T instance;

    public static T Instance { get { return instance ?? (instance = create()); } }

    private sealed override void OnClosed(EventArgs e)
    { 
        instance = null;
    }
}

public class MyWindow : Singleton<MyWindow>
{
    static MyWindow()
    {
        create = () => new MyWindow();
    }

    private MyWindow() { }
}

Then you can access the instance on your derived class as if it was a normal singleton.

var myWindow = MyWindow.Instance;
christophano
  • 915
  • 2
  • 20
  • 29