Is this an existing pattern

[sadavoya]

Does the following C# code belong to a design pattern? If so, which one?

public class Fee
{
    private Bar<Baz>.Getter myBaz = Bar<Baz>.GetAGetter();

    public void Fi()
    {
        myBaz().DoStuff();
    }
    public void Fo()
    {
        myBaz().DoStuff();
    }
}
public class Bar<T>
    where T : new()
{
    public delegate T Getter();

    public static Getter GetAGetter()
    {
        T requestedItem = default(T);
        return () =>
            {
                if (requestedItem == null)
                {
                    requestedItem = new T();
                }
                return requestedItem;
            };
    }
}
public class Baz
{
    public Baz()
    {

    }
    public void DoStuff()
    {

    }
}

Bar returns a closure with an upvalue of type T. In this example, Fee's myBaz method will always return the same Baz object, and it won't be instantiated until the call to myBaz().DoStuff() during either the Fee.Fi() or Fee.Fo() method, whichever is called first. So basically Bar provides lazy initialization of a Baz (in this case) to Fee (and presumably other classes). Do we have a name for this? If this question has already been asked in this forum, please point me to the message.

[CodingYoshi]

At a quick glance, seems like a Singleton but a Generic Singleton Pattern. May I ask why it is important to know whether the pattern exists or not? Patterns come with time when they have proven to be successful solutions. What unique problem does your pattern above solve or why do you need such a pattern? Is it making things easier or harder?

CodingYoshi Artificial Intelligence is no match for Human Stupidity.

[sadavoya]

I'm mostly curious. I'm wondering if such a pattern, or something similar (or better or more fully thought out) has emerged already in the community. I know this code doesn't match a GOF pattern, and that it looks like a not-very-good singleton. You might call it a singleton for the calling scope of Bar.GetAGetter(). There's nothing to prevent two scopes from getting separate values though. Indeed, a single scope can get two separate values simply by calling Bar.GetAGetter() twice - each call returns a method that returns a distinct value. This is by design - it's not supposed to be a singleton. Like I said, I think the value of Bar is that it encapsulates lazy instanciation. Since lazy instanciation is very common, and it takes 3-5 lines of code every time, and this replaces it with 1 line of code, encapsulating it seems like a good idea for all the usual code reuse reasons.