Is InvokeMember limited in Silverlight 3?

Greetings

There’s a good explanation about this on: http://www.yoda.arachsys.com/csharp/singleton.html

Check version 4 and 5

Nr 4 explains how the static way of working works, while nr 5 is just the next step after having that knowledge and making it lazy.

Can you explain why working with an inner class makes it threadsafe?

I think when 2 threads try to access the “get” of the enclosing class they both are redirected to the inner class where they could access the if loop at the same time again.

Probably I am missing some basic functionality about how inner classes work but atm I would go for the adding the synchronized on top in the method signature.

Long ago, when I was young :p, I used the Singleton in a project, and after that I didn’t touch it anymore for years, until this article.

As with most of good programming, you tend to “feel” things. And Singleton usually never shows up in my feelings when architecting something.

Nice catch

If you by mistake are sloppy and don’t add a private one (default public) or add a public one, the code will crash at runtime, giving you a chance to fix it

I work with Maxim at Orckestra

I definitely based it on the yoda.arachsys page, after I completed it, I found a few similar implementations.

Thanks for your input as well. Seems Reflection is indeed the way to go

I updated the code and made a follow-up blog post on this Generic Singleton Pattern (dubbed like that by me right now :p)

http://blog.cumps.be/design-patterns-generic-singleton-pattern/

Thanks for your input guys!

public static class TypeHelper
{
public static T InvokeParameterlessConstructor() where T : class
{
return typeof(T).InvokeMember(typeof(T).Name, BindingFlags.CreateInstance | BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public, null, null, null) as T;
}
}

This is used to invoke the constructor even if the constructor is private.

However, we must make sure that the class will stay valid with this invoke so I would use it for local components but not with 3rd party.

Cheers

Can you post a piece of your Singleton code to illustrate this please?

However, after reading this post I see that this is not the case

Anyone know where I got that from? Or if it’s a misunderstanding of some sort?

Seems you had the same idea as Andrew, just started approving comments in the moderation queue

Nice implementation as well. I’ll be settling for the following right now, and will create another post on it to start a discussion about possible drawbacks of it.

(Code will look crappy in comments, sorry, tommorow’s blog post will make it look better :p)

public class Singleton< T > where T : class
{
protected Singleton() { }

public static T Instance
{
get { return Nested.Singleton; }
}

private sealed class Nested
{
private static readonly T _instance = typeof(T).InvokeMember(typeof(T).Name,
BindingFlags.CreateInstance | BindingFlags.Instance | BindingFlags.NonPublic,
null,
null,
null) as T;

internal static T Singleton
{
get { return _instance; }
}
}
}

Thanks for the comment! Great idea there

It seems you have implemented it as the following version: ‘Fourth version – not quite as lazy, but thread-safe without using locks’, from the article I linked (http://www.yoda.arachsys.com/csharp/singleton.html)

I took a moment to try and apply it to this version as well: ‘Fifth version – fully lazy instantiation’, and am happy with the result, thanks for inspiration!

It’ll be included in the future solutions for this series, and I’ll post an update tomorrow with credits. (Too tired now :p)

Though the Instance property needs to be changed, as it uses the C# 3.0 syntax. Other than that, its pretty awesome.

public class Singleton where T : class
{
// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static Singleton()
{
}
public static readonly T Instance = TypeHelper.InvokeParameterlessConstructor();
}
public static class TypeHelper
{
public static T InvokeParameterlessConstructor() where T : class
{
return typeof(T).InvokeMember
(
typeof(T).Name,
BindingFlags.CreateInstance | BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public,
null, null, null
)
as T;
}
}

I normally use the first approach. First reason is that I haven’t had time to find a good fix for the generic version and having a public parameterless constructor is not a Singleton.

Next, I rarely need to use a Singleton myself so I often cut to the chase and just use the nested class approach without generics.

The only place I see the singleton used a lot is for data repository (see Martin Fowler Enterprise Patterns for this one) but since they are generated by an ORM I don’t have to bother with that.

So for me, Solution #1.

Cheers