Settings class in C# application I made a settings class for my own C# application. My main goal was to reach this class from every other class (this is why I choose the Singleton pattern). I also wanted to distinguish the different type of settings, so I added GeneralSettings and made it public. Do you know any other ways which I can tell apart the different type of settings? I thought about namespaces, but those are not allowed in classes.

I also wanted to make sure that I can restore its state if the user don't want to save the changes made in the settings dialog. What is your opinion about my implementation? Now I need to call SetRestorePoint and if I want to discard changes Restore.

public class Settings : ISerializable
{
    private Settings ()
    {
    }
    static private Settings _instance = null;
    static private Settings _restoreInstance = null;
    static public  Settings Get //Singleton
    {
        get
        {
            if (_instance == null)
                _instance = new Settings ();

            return _instance;
        }
        private set { }
    }

    public void SetRestorePoint ()
    {
        _restoreInstance = DeepClone (_instance);
    }
    public Settings Restore ()
    {
        _instance = _restoreInstance;
        return _instance;
    }

    public GeneralSettings General = new GeneralSettings ();

    [Serializable] 
    public class GeneralSettings
    {
        public bool isAutomaticSave = false;
    }

    private static T DeepClone&lt;T&gt;(T obj)
    {
        using (var ms = new System.IO.MemoryStream ())
        {
        var formatter = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter ();
        formatter.Serialize (ms, obj);
        ms.Position = 0;

        return (T) formatter.Deserialize (ms);    
        }
    }
    //serialization...
}


How have people implemented Settings in bigger software?
The indentation isn't always consistent, e.g. the using scope in DeepClone should be indented a level.

Get property should probably be named Instance (a noun), or remain Get (a verb) and be turned into a method. The private and not implemented setter is sloppy, and the = null initialization of the backing private field is redundant.

Seems the restore mechanics are written with a specific UI in mind, where the UI immediately saves changes - typically a settings dialog would do something when the user confirms or applies modifications; seems your model is the other way around - the changes are saved unless they're cancelled, so cancelling changes requires work... seems backwards.

I'd remove that cloning and restore functionality, and make the UI work differently, off a ViewModel - not directly with the settings; when the dialog is cancelled, you have nothing to revert or restore (no changes were made), and when the dialog is okayed and/or changes are applied, then you persist the changes using your settings service.

I think a Singleton isn't needed for this, provided that the rest of the code isn't responsible for newing up anything; if you make that responsibility the job of an IoC container, then it's child's play to configure it in such a way that any class with an ISettingsService constructor parameter will always receive the same instance of whatever concrete type implements that interface - that's OOP with Dependency Injection at play, and static members don't play very well with OOP (static members belong to the type, not to an object), so the more of it you have in your code base, the more coupling you have everywhere between unrelated classes...