Надлежащее использование статического метода

Пока я согласен с другими ответами, что в большинстве случаев это, безусловно, имеет смысл.

Иногда вам может потребоваться немного больше гибкости, определив интерфейс и реализовав его с помощью методов экземпляра. Это дает вам возможность использовать разные методы в вашем коде в будущем.

Вот пример того, что я имею в виду. Допустим, вы используете этот ваш formatString метод в каком-то коде, который выглядит примерно так:

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

Хорошо, это здорово. (На самом деле, это глупо, но что угодно - только для иллюстрации!) Но вы могли бы сделать такой метод более гибким, если бы он принимал интерфейс, из которого у вас могут быть различные реализации, которые предоставляют совершенно разные виды форматирование:

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));
    }
}

Тогда вместо StringUtils, являющегося статическим служебным классом, это будет просто одна реализация класса, который предлагает способ форматирования определенного типа объекта (в вашем случае string объектов; в моем примере это воображаемые DataField объекты).

Так что это очень длинный способ сказать, это зависит от обстоятельств. Если вы стремитесь к сверхгибкости в будущем, возможно вам следует подумать о реализации интерфейса вместо использования статического вспомогательного класса.

Обратите внимание, что в моем примере выше другим вполне приемлемым способом решения проблемы могло бы стать принятие Func<T, string> делегата вместо этого гипотетического IFormatter<T> интерфейса. На мой взгляд, это в основном стилистический выбор. Но часто интерфейсы становятся более реалистичными, когда вы хотите настроить несколько вариантов поведения; то есть определение методов, которые принимают 3, 4 или более делегатов, может быстро стать громоздким по сравнению с принятием одного интерфейса.

Да, если у вас есть несколько статических методов, которые обычно связаны, объединение их в статический служебный класс - хорошая идея.

Если вы говорите о соглашении, также стоит отметить, что соглашения об именах в большинстве кодов .NET вызывают общедоступные члены на основе Pascal (так FormatString вместо formatString) и параметры и поля в стиле верблюда (так inputString вместо InputString).

Если вы делаете их общедоступными, то да, потенциально может быть лучше сделать какой-нибудь служебный класс.

При этом я бы постарался сделать его как можно более «универсальным», поскольку в противном случае они, как правило, быстро становятся недоступными для обслуживания.

Да, статические методы в том виде, в каком они используются в C #, очень похожи на идею C ++ о «бесплатных функциях». Так уж получилось, что в C # нет бесплатных функций. У Эрика Липперта есть интересный пост о том, почему это так. Статический класс используется для группировки функций схожей полезности и был бы уместен, если бы у вас было несколько из них, которые были бы похожи.

Да, нормально, тогда ваш класс будет действовать как «библиотека» связанных функций. Другой ваш выбор для этого - либо загрязнить глобальное пространство имен различными функциями, либо создать синглтон, который был бы ненужным, поскольку нет `` состояния '' для учета ...

Да, ты мог бы это сделать. Или вы можете создать метод расширения строки.

методы расширения msdn

В приведенном выше примере я бы использовал средство форматирования строк вместо встроенной конкатенации.

string.Format("some formatting {0} some other formatting", inputString )

Это если это конкретное форматирование будет полезно более чем в одном месте вашего кода.

Если бы это имело смысл только в одном конкретном классе, я бы предпочел использовать частный метод (статический или экземплярный, это не имело бы значения).

Полезные классы - вещь полезная. Единственное, о чем следует быть осторожным, - это не использовать их слишком часто. Если большая часть вашего кода находится в служебных классах, значит, вы делаете что-то не так. Но выделение некоторого общего кода во вспомогательных методах - вполне оправданное использование.

Для этого вы можете использовать метод расширения, чтобы расширить класс String. Это сделало бы код вызова немного более аккуратным, но, в конце концов, это всего лишь вопрос личного вкуса.

    public static string MyWeirdFormat(this string str)
    {
        return string.Format("{0} is weird",str);
    }

    public static void Test()
    {
        string myString = "ABCD";
        string weirdString =  myString.MyWeirdFormat();
    }

На мой взгляд, да, вы бы поместили эти методы в класс Utility (Утилита). В веб-приложении Java, над которым я сейчас работаю, у нас есть 3 таких класса Util, каждый из которых состоит только из статических методов, подобных тому, который вы показали. Причина, по которой у нас есть 3, - это один только для клиентских методов Util, один только для сервера и третий для общих методов Util.

В зависимости от того, какое у вас приложение, вы можете получить что-то похожее.

Кстати, если вы хотите узнать больше о том, когда использовать статические классы в C #, посмотрите здесь.

Надеюсь, вы достаточно ответили на ваш вопрос.

Лично я больше склоняюсь к использованию метода расширения, хотя и статичного;)

public static class StringExtensions
{
    public static string MyFormat(this string input)
    {
        return string.Format("some formatting {0} Some other formatting", input);
    }
}