Different Kind Of Factory?

21 commentsWritten on March 4th, 2009 by
Categories: Software Development

I was just refactoring some code and there were a few places in a class where we needed to instantiate a new instance of something, based on a key... could've used a factory class there, right? Instead i did this:

        private readonly Dictionary<string, Func<IPanel>> panelFactory = new Dictionary<string, Func<IPanel>>

            {

                { typeAndSizeKey, () => new TypeAndSizePanel() },

                { phaseKey, () => new PhasePanel() },

                { organisationStructureKey, () => new OrganisationStructurePanel() },

                { incidentDataKey, () => new IncidentDataPanel() },

                { processesKey, () => new ProcessesPanel() },

                { generalInfoKey, () => new GeneralInfoPanel() },

                { linksKey, () => new LinksPanel() }

            };

and now, when i need to create a new instance i just do this:

panelFactory[myKey]()

i kinda like the simplicity

« Updated Reading ListWhat Should I Talk About In A Presentation About NHibernate? »

This entry was posted on Wednesday, March 4th, 2009 at 12:57 and is filed under Software Development. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

  • http://www.juanformoso.com.ar Juan Manuel

    I’m a bit rusty with lambdas and all that… this doesn’t create an instance until you call the appropriate key, right?

  • http://davybrion.com Davy Brion

    The Dictionary returns the appropriate lambda (well, the Func actually) which is associated with the given key… only when you execute the return value of the dictionary is the lambda actually executed.

    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

  • http://mrpmorris.blogspot.com Peter Morris

    Very nice :-)

  • Kevin Swiber

    I recently used similar code. Very cool. This works great when you only need to create objects within a single class. If changes are made and at least one outside class suddenly needs to access that Dictionary object, it gets to be a small pain when using “magic strings.” It feels safer using an enum as the key or refactoring to a typical factory class. (Small point, but obvious.) Also, if you have a ton of potential keys, an internally accessible enum is a better way to go (IMHO). Intellisense = godsend.

  • http://davybrion.com Davy Brion

    yes, one of my coworkers (hi peter!) asked me why i didn’t use an enum, so i eventually caved and started using an enum as the key

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

  • Peter

    You bake the cake, I put the little cherry on top! ;-)

  • http://davybrion.com Davy Brion

    @Peter,

    that comment just cost us our ‘coolness’-factor

  • Pingback: Arjan`s World » LINKBLOG for March 4, 2009

  • Stew

    If you know enough about what type of object you need to be able to specify a “key” to the factory, don’t you know enough to just call the constructor of the class?

  • http://davybrion.com Davy Brion

    @Stew,

    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.

  • Stew

    @Davy,

    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?

  • http://davybrion.com Davy Brion

    the class i used this in has to manage the currently visible panels… this means it has to create the initial panel instances, but it also occasionally has to replace a panel with a new instance. Deciding which specific panel type to instantiate was one ugly switch statement, plus the instantiation statements were in 2 separate locations.

    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

  • http://blechie.com/wpierce/ Bill Pierce

    Not using Windsor in your project?

  • http://davybrion.com Davy Brion

    @Bill

    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 ;)

  • http://rant.blackapache.net/ OJ

    To be honest I don’t see this as anything other than abuse of syntactic sugar resulting in less readable code. How is this any better than a function with a switch statement?

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

    Cheers :)
    OJ

  • http://davybrion.com Davy Brion

    @OJ

    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.

  • Kevin Swiber

    @OJ

    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. ;)

  • http://davybrion.com Davy Brion

    @Kevin

    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.

  • http://rant.blackapache.net/ OJ

    Thanks for the responses guys. I don’t exactly have a problem with the idea of a dictionary. The gratuitous lambdas which result in statements like this:

    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!

  • John

    @OJ
    If you needed to do what is being done here how would you go about rewriting it?

    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.

  • http://rant.blackapache.net/ OJ

    Good question John :) Time for me to show my hand eh? Let me just go dig one up.

    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

Meta

Recent Posts

Categories

Archives