CODEWITHSUNDEEP
c#reflectionsingletonsystem.reflection
Brian
Brian

Reputation: 1397

Singleton vs GetSafeUninitializedObject

I came across this answer by Marc Gravell on how to create an object without calling its constructor. Can someone confirm this will not circumvent even the complete and best implementation of singleton pattern(Reference implementations here. And why? I guess more specifically I am not clear on the inner workings of GetSafeUninitializedObject() in the context of a Class's constructors (static, private etc)

Upvotes: 1

Views: 370

Answers (4)

Oliver
Oliver

Reputation: 45119

Within the singleton pattern you have a static variable on your type that will be initialized by the type constructor.

By calling GetSafeUninitializedObject you only avoid the instance constructor which will be called after the type constructor.

Example:

public sealed class Singleton
{
    private static readonly Singleton instance = new Singleton();
    private static string _StaticMessage = "Type ctor;";

    private string _Message = "init; ";

    static Singleton()
    { }

    private Singleton()
    {
        _Message += "ctor; ";
    }

    public static Singleton Instance
    {
        get { return instance; }
    }

    public string Message { get { return _StaticMessage + _Message; } }
}

internal class Program
{
    private static void Main(string[] args)
    {
        var singleton = Singleton.Instance;
        // writes "Type ctor;init; ctor;"
        Console.WriteLine(singleton.Message);

        var instance = (Singleton)System.Runtime.Serialization.FormatterServices
        .GetSafeUninitializedObject(typeof(Singleton));

        // writes "Type ctor;"
        Console.WriteLine(instance.Message);
    }
}

Update to clarify difference between type initializer and static ctor asked from IllidanS4

This doesn't really belong to the answer above, but to the question within the comments: And a answer simply doesn't fit into a simple comment.

@IllidanS4: The type initializer is just a shortcut for writing an implicit static constructor. If you create a class that contains both initialization methods and decompile the resulting assembly you can see only one static constructor (.cctor) that will initialize all the variables. The both assignments will be merged where the type initializer will be called first and the statements within the static constructor last.

Take this sample class:

internal static class C
{
    public static readonly string ByTypeCtor;
    public static readonly string ByTypeInitializer = "From type init; ";
    public static string ByBoth = "From type init; ";

    static C()
    {
        ByTypeCtor = "From static ctor; ";
        ByBoth += "From static ctor";
    }
}

If you compile it and afterwards decompile it (e.g. by using ILSpy) you'll get the following code back:

internal static class C
{
    public static readonly string ByTypeCtor;
    public static readonly string ByTypeInitializer;
    public static string ByBoth;
    static C()
    {
        C.ByTypeInitializer = "From type init; ";
        C.ByBoth = "From type init; ";
        C.ByTypeCtor = "From static ctor; ";
        C.ByBoth += "From static ctor";
    }
}

Due to this fact i normally never use to initialize a variable directly when it will be declared. Instead i always leave them uninitialized (like the ByTypeCtor variable) and make all initializations within the constructor. This simply avoids cluttering variable initialization to different positions within the class which improves maintainability.

Upvotes: 2

Chris Leyva
Chris Leyva

Reputation: 3526

As everyone has mentioned, it can circumvent and undermine your design pattern. But take a look at the recommended usage for GetSafeUninitializedObject

According to MSDN:

GetSafeUninitializedObject should only be used for deserialization when the user intends to immediately populate all fields. It does not create an uninitialized string, since creating an empty instance of an immutable type serves no purpose.

Upvotes: 2

Tigran
Tigran

Reputation: 62265

Yes, the default Singleton pattern is definitely better in most situations. The expected behaviour of your type, is that it's ctor has to be called.

Creating an object without calling ctor method on that type, is not something "normal", so I, personally, would always avoid using this solution till have really strong reasons to do so.

Side note: the singleton pattern is just a pattern and not framework behaviour. In my opinion, in this question, you mix 2 concepts that don't mix together.

The first case is a way to create an object, the second case, is a way to architect code.

General rule is: don't do "strange things" (GetSafeUninitializedObject is strange one), till you really need do so. Keep goinig on common shared across all developers patterns and keep things simple as much as it possible.

Upvotes: 1

RogerN
RogerN

Reputation: 3821

The GetSafeUninitializedObject method works even on objects with private constructors, so it could potentially be used to circumvent the singleton pattern.

Upvotes: 1

Related Questions