I was recently reviewing a few Helper-style "utility bag" static classes floating around some large C# codebases I work with, things basically like the following very condensed snippet:
// Helpers.cs
public static class Helpers
{
public static void DoSomething() {}
public static void DoSomethingElse() {}
}
The specific methods I've reviewed are
- mostly unrelated to each other,
- without explicit state persisted across invocations,
- small, and
- each consumed by a variety of unrelated types.
Edit: The above is not intended to be a list of alleged problems. It's a list of common characteristics of the specific methods I'm reviewing. It's context to help answers provide more relevant solutions.
Just for this question, I'll refer to this kind of method as a GLUM (general lightweight utility method). The negative connotation of "glum" is partly intended. I'm sorry if this comes across as a dumb pun.
Even putting aside my own default skepticism about GLUMs, I don't like the following things about this:
- A static class is being used solely as a namespace.
- The static class identifier is basically meaningless.
- When a new GLUM gets added, either (a) this "bag" class gets touched for no good reason or (b) a new "bag" class gets created (which in itself is not usually an issue; what's bad is that the new static classes often just repeat the unrelatedness problem, but with fewer methods).
- The meta-naming is inescapably awful, non-standard, and usually internally inconsistent, whether it's
Helpers
,Utilities
, or whatever.
What's a reasonably good & simple pattern for refactoring this, preferably addressing the above concerns, and preferably with as light a touch as possible?
I should probably emphasize: All the methods I'm dealing with are pairwise unrelated to each other. There doesn't seem to be a reasonable way to break them down into finer-grained yet still multi-member static class method-bags.