статический дизайн класса? - PullRequest
1 голос
/ 19 октября 2011

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

   public class SettingsHelper
{
    public static readonly string MinVal= "MinVal";
    public static readonly string MinPartners = "MinPartners";

    public static IDictionary<string, string> GetSettings(string jsonsettings)
    {
        var settings = JsonConvert.DeserializeObject<Dictionary<string, string>>(jsonsettings);
        return settings;
    }


    public string SettingsToJson(IDictionary<string, string> settings)
    {
        var jsonsettings = JsonConvert.SerializeObject(settings);
        return jsonsettings;
    }


    public static decimal GetMinPartners(string jsonsettings)
    {
        var settings = GetSettings(jsonsettings);

        string partners;
        settings.TryGetValue(MinPartners, out partners);

        return decimal.Parse(partners);
    }

    public static int GetMinValue(string jsonsettings)
    {
        var settings = GetSettings(jsonsettings);

        string pival;
        settings.TryGetValue(MinVal, out pival);

        return int.Parse(pival);
    }

}

Я хочу включить такие методы, как, партнеры по обновлению,добавить партнеров и т.д ...

Ответы [ 4 ]

2 голосов
/ 19 октября 2011

Я не вижу никакой выгоды в том, что он статичен? Он работает просто отлично, чтобы создать его экземпляр там, где это необходимо.

Я бы назвал это ConfigurationRepository хотя. Это описывает намерение лучше. Также я бы переместил сериализацию во второй класс, чтобы сохранить ясность обязанностей.

1 голос
/ 19 октября 2011

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

Статический класс имеет смысл, если,

- все ваши методы статичны
-вы не держите в классе никакого глобального состояния.
Вы не изменяете ни одну из переменных-членов.
-все ваши функции являются "вспомогательными" по своей природе.
-Ваш класс не создает цепочку других статических классов.

Что касается поточной безопасности, поскольку ваш класс не изменяет никакое глобальное состояние (любую переменную-член), он является поточно-ориентированным.

0 голосов
/ 19 октября 2011

Я предполагаю, что под 'статическим классом' вы подразумеваете класс только со статическими методами.

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

Есть несколько приемлемых причин для статических методов, таких как

  • нет состояния
  • альтернативные реализации действительно не нужныНе имеет большого смысла

Это может применяться в вашем случае.=> так что дизайн может быть в порядке.

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

Клиенты ваших методов / классов получат экземпляр вконструктор, возможно, с конструктором по умолчанию, который создает нормальные экземпляры.

Вот что вы получите:

  • При тестировании клиентов вы можете легко предоставить постоянные ответы с ложными ссылками,вам не нужно использовать допустимые строки JSON.В случае клиентов, которые сами не создают эти строки, это предотвращает множество сбоев, не связанных с реальным тестируемым классом, когда изменяется структура вашей строки json.

  • Когда однажды некоторые изэта информация поступает из xml, базы данных или гадания, особенно если это различие сделано клиентом и не является типом информации, его будет легко переключать.

0 голосов
/ 19 октября 2011

это должен быть статический класс, тем более, если все ваши функции в классе статические ... есть данные или поведение в классе, которое зависит от идентичности объекта?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...