Where to put common shared methods

Question

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

Answer 1

The namespace could be [application].Common.Shared

Classes could be named:

ConversionLookup
ClipboardCommunication
FontManager
DrawingUtility

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

Answer 2

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.

Answer 3

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.