1

I want to call it a "Helper" but this seems way too general.

Let's say I have a class called WidgetCranker and WidgetCranker can be set up to crank out widgets of the type Square, Keyhole and GearShape. I can also specify which Color I want my widgets to be and which Label I want stamped on them.

Now, setting up each individual instance of WidgetCranker is fairly involved, the constructor just gives you an empty WidgetCranker and you have to manually set the type and colour of widgets you want to crank.

WidgetCranker keyholeWidget = new WidgetCranker();
keyholeWidget.Type = WidgetTypes.Keyhole;
keyholeWidget.Color = WidgetColors.Red;
keyholeWidget.Label = "ACME Industries Prototype 1";

But I have a class that requires a lot of WidgetCrankers that pretty much all look the same except for the label. I want to make my code more readable and less laborious to maintain, so I create a helper class that does all the lifting for me. So the above now becomes:

WidgetCranker keyholeWidget = WidgetCrankerHelper.RedKeyhole("ACME Industries Prototype 1");

My question is twofold:

  1. Is this an actual design pattern and if so, what do we call it? I want to call it a factory, but it most definitely isn't a factory pattern. We're creating exactly the same kind of object in every case, just instantiating them differently. I know it's a type of "Helper", but I want to be more specific than that if I can. It's a helper that does a very specific thing.

  2. Given that "Helper" is a very generic name, I feel that just naming the method by what it produces isn't enough. I should name it so that it's obvious what it does. So would MakeRedKeyhole be better or BuildRedKeyhole? I don't want to use GetRedKeyhole because that implies we're getting back a reference to an existing instance and not creating a brand new one.

Iain Fraser
  • 6,578
  • 8
  • 43
  • 68
  • 3
    Its still a factory.. just _not an abstract factory_. – Simon Whitehead Jul 15 '13 at 02:53
  • definitely a factory :) – Keith Nicholas Jul 15 '13 at 02:55
  • There you go. Thanks guys. I was thinking of abstract factories and got myself in a pickle. – Iain Fraser Jul 15 '13 at 02:57
  • 3
    a factory can return different types of concrete objects. However its still valid to return simply objects configured differently as opposed to different types. – Keith Nicholas Jul 15 '13 at 03:00
  • This is the Factory Method pattern (http://en.wikipedia.org/wiki/Factory_method_pattern - scroll down for C# sample code), and is commonly implemented as static methods on the class itself. – Morten Mertner Jul 15 '13 at 03:03
  • Cool, that was my other problem with calling it a factory. I wasn't sure that you could still call it a factory if all it was doing was configuration on one type of object (i.e. not different implementations of an interface, just plain simple configuration on a single class of object). – Iain Fraser Jul 15 '13 at 03:13
  • 2
    A [Builder][1] pattern should also be considered. [1]: http://stackoverflow.com/questions/757743/what-is-the-difference-between-builder-design-pattern-and-factory-design-pattern – David Osborne Jul 15 '13 at 10:48

1 Answers1

0

I tend to stay away from the term "Helper" as all classes are supposed to be helpful, right? :)

I think that calling this either Factory or Builder would be acceptable. The point of abstract factory is to encapsulate the construction/instantiation of an object. It could return different types, but it doesn't need to. The type consuming the factory shouldn't care.

I tend to use the "Builder" name when it is doing any complex construction like this.

Martin Cron
  • 1,154
  • 1
  • 8
  • 10