To be honest, I think it would vary depending on what was going on. But on the surface I would do exactly what you described in your last comment, though I might not go as far as having a registration mechanism. A simple switch based on type might be all that’s needed.

The crux of my “gripe” (for want of a better word) is that I find the manner in which the code has to be invoked rather unintuitive. If you wrapped up your current mechanism in a factory function I’d be a lot more comfortable with it. You’d have a simple function call through your code instead of foo[bar]();

Having said all that, your post is an interesting snippet of how you might use lambdas in this case, but just coz you can doesn’t mean you should

Thanks again Cheers!
OJ

Personally if improving readability is the aim (which of course is a key factor) I would create an actual factory which had an interface which I could add registrations to and then have a method by which I could retrieve registrations based on a key value. Under neither, the structure could do anything (i.e. use a dictionary, switch statement, or something else like an IoC).

But in if this pattern was going to be common in my code I probably would use an IoC.

panelFactory[myKey]()

.. is really where my issue lies. It’s not immediately obvious what’s going on there. I guess I personally don’t see how this is actually any different to a switch (other than arguably slower?).

Each to their own, so long as I don’t have to maintain it Cheers lads!

we’re not using Prism or Caliburn (though i have been meaning to look into those). We’re currently using a custom solution which is based on my ASP.NET MVP approach with some extra’s thrown in for databinding.

I understand everyone has their own opinion, but for me, something like this helps create concise and readable code. That’s all. “Syntactic sugar” gets thrown around quite a bit these days as if it’s a bad thing. I would say this is the use of syntactic sugar, not an abuse of it. I see this kind of code for operations that are class-internal and isolated. It’s quick to write, the intent is easy to understand, and it’s useful. Also, it’s pretty easy to refactor if its use explodes. No big deal.

@Davy

Silverlight, eh? Using the MVVM pattern (aka WPF/SL-specific Presentation Model pattern) that’s gaining popularity? Prism? Caliburn? Whatever you’re using, I wouldn’t mind reading a post about it in the near future, if I might make a suggestion.

i guess it kinda depends on how you feel about switch statements… personally i try to avoid them as much as possible. As for readability, i’ll take the dictionary over a switch any day as well.

The “Coolness” factor isn’t justification for use of languages features. Where’s the value-add?

Cheers
OJ

not in the silverlight code

we’re actually using a lightweight custom IOC container implementation in our silverlight code, but i use it for ‘real’ code, not the UI stuff

the server-side business layer uses Windsor all the way of course, i wouldn’t have it any other way

Now, the code that deals with replacing panels doesn’t even need to know anything about which type of panel it needs to remove and create again. It receives a value (previously the string key, but that’s already been changed to an enum value) from an external component, and uses the dictionary-based factory to create a new instance and replace the previous instance (which is also stored in a dictionary based on the key/enum value) with the new one. What used to be a switch statement has now become something like: SwitchPanel(key, panelFactory[key]()) which in turn can do something like:

var previousPanel = currentPanels[key];
previousPanel.Dispose();
currentPanels[key] = newPanel;

The only place where the actual types of the panels are used is in the dictionary-based factory, nowhere else

I’m wondering if you find some advantage in using this method in the two situations where you replaced the direct constructor calls? Obviously, the need for IPanel is controlled by the class to which you are passing the concrete instance.

It seems to me that you would have some clear advantages by calling the constructor directly, such as the ability to discover usages of the class and compiler errors in any places where you may be using properties/methods specific to the concrete implementation.

Are you realizing some benefits that offset these concessions?

that was exactly what i was trying to get away from in this class… these panels were instantiated whenever they were needed (which was in 2 situations) and i just didn’t like it. Also, the code that uses these panels only needs to have an IPanel instance, it doesn’t really care about what specific panel it is.

that comment just cost us our ‘coolness’-factor

to be honest, it was mostly out of laziness why i didn’t use an enum in the first place

So yes, it only instantiates the objects when you retrieve the correct func and execute it… you could also use it like this:
var myCreationFunction = panelFactory[myKey];
myCreationFunction(); // this actually instantiates the panel