I have a bunch of methods that are commonly used everywhere. Right now the codefile is named globals, to represent the fact that they are... in fact... global.

However, I do not like this.

I want to group these into a class and pass an interface around. I'll make only one instance, but I'm not falling into the singleton trap here.

First of all, what should I name the class. I want to avoid the globals name because I'm afraid maintainers would get the wrong idea.

Also, how should I consider splitting up such a set of methods so that behavior can change and adapt?

The set of methods contains stuff like:

  • Conversion tables
  • Clipboard interaction
  • Managing built fonts
  • Common drawing methods
  • Providing an interface with access to often used resources
  • Are these like pure Util methods which don't save state or do they save state? – TheLQ Aug 10 '11 at 22:18
  • +1 for not falling into the singleton trap. – Caleb Aug 11 '11 at 2:12
  • @TheLQ They won't necessarily save state, but they'll hold const data (like conversion charts) for convenience. – Lee Louviere Aug 12 '11 at 15:39

The namespace could be [application].Common.Shared

Classes could be named:


I would break up the classes because it sounds like they do different things.

| improve this answer | |

If you are going to make one instance, you pretty much have a singleton. Also, the thing people would normally be referring to if they talk about a singleton trap is that singletons are global, and most classes are better off not being global. So you might as well have a singleton. If you can reasonable pass an interface around to objects that might want to call it then it isn't really global.

Also, putting it all in one grab-bag of global methods makes it difficult to have the behavior change and adapt since not only does each change to one method necessitate a new subclass, but each combination of changes would need it's own subclass.

I would recommend having singletons for each one that truly is global (I'll take your word they all are) and some kind of registry or factory that gives you an instance (which means you can implement as singleton or not, since the interface will make no promises). I would name them based on what they do from the caller's perspective.

| improve this answer | |

I normally put these types of things in their own assembly names something like "foo.Common" under a namespaces like "foo.Common.Collections" or "foo.common.UI" etc. then, I can reference the assembly in whatever project I need them.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.