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

Question

Концептуально, уместно ли использовать статический метод (C #), когда метод будет принимать только входные данные и переформатировать входные данные в качестве выходных? Например:

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

Если бы у меня было несколько таких методов, был бы статический класс "утилиты" хорошей идеей?

Answer 1

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

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

Answer 2

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

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

Вот пример того, что я имею в виду. Скажем, вы используете этот 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 или более делегатов, может быстро стать громоздким по сравнению с принятием одного интерфейса.

Answer 3

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

В зависимости от того, какое у вас приложение, у вас может получиться нечто подобное.

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

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

Answer 4

Вы можете использовать метод расширения для этого, чтобы расширить класс 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();
    }

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

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