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, 2011 at 22:18
  • +1 for not falling into the singleton trap.
    – Caleb
    Aug 11, 2011 at 2:12
  • @TheLQ They won't necessarily save state, but they'll hold const data (like conversion charts) for convenience. Aug 12, 2011 at 15:39

3 Answers 3


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.


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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