Question

Conceptually, is it appropriate to use a static method (C#) when the method will only take inputs and reformat the input as the output? For example:

public static string FormatString(string inputString){
  return "some formatting" + inputString + "Some other formatting";
}

If I were to have a few of these types of methods, would a static “utility” class be a good idea?

Answer 1

I’d agree with the other answers so far that it certainly makes sense a lot of the time.

Sometimes, you may want to actually give yourself a little more flexibility by defining an interface and implementing that with instance methods. This gives you the option of using different methods in your code down the road.

Here’s an example of what I mean. Say you are using this formatString method of yours in some code somewhere that looks like this:

public void DumpToConsole()
{
    foreach (DataField field in m_fields)
    {
        Console.WriteLine(StringUtils.formatString(field.ToString()));
    }
}

OK, this is great. (Actually, it’s stupid, but whatever—for illustration only!) But you could make such a method more flexible by having it accept an interface, of which you might have various implementations which provide completely different sorts of formatting:

public void DumpToConsole(IFormatter<DataField> formatter = null)
{
    // Perhaps you could specify a default. Up to you.
    formatter = formatter ?? Formatter<DataField>.Default;

    foreach (DataField field in m_fields)
    {
        Console.WriteLine(formatter.Format(field));
    }
}

Then instead of StringUtils being a static utility class, it would be merely one implementation of a class that offers a way to format a certain type of object (in your case, string objects; in my example, these imaginary DataField objects).

So this is all a very long-winded way of saying, it depends. If you’re aiming for super flexibility down the road, maybe you should consider implementing an interface instead of going with a static helper class.

Do note that in my example above, another completely acceptable way of approaching the problem could’ve been to accept a Func<T, string> delegate instead of this hypothetical IFormatter<T> interface. This is mostly a stylistic choice, in my opinion. But often interfaces become more realistic when there are multiple behaviors that you want to customize; i.e., defining methods that accept 3, 4, or more delegates can quickly become cumbersome compared to accepting a single interface.