Мнение о создании статического класса общего пользования

Question

Часть того, что я читал об этом вчера и сегодня:

• (SO) Стоит ли избегать статических классов?
• (SO) Когда использовать статические классы в C # - Марк С. Расмуссен делает хороший комментарий здесь
• Синглтон против статики - Хорошая цитата здесь:

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

• Синглтон считается глупым
• (SO) Класс с одним методом - лучший подход? - Еще раз, цитата из Марка С. Расмуссена:

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

• (SO) Методы создания всех статических в классе - Скорость для меня сейчас не проблема, код должен работать * СОБСТВЕННО * при вызове несколькими клиентами с веб-сайта и от (возможно, но маловероятно) нескольких клиентов из приложения администратора.

В настоящее время мы (я) заняты переписыванием наших основных приложений, и один из проектов в решении - "Общий", и он содержит один класс "clsCommon". Этот класс не имеет свойств, единственный закрытый метод, который вызывается как единственная строка в конструкторе, а затем просто открытые методы.

Этот класс обрабатывает такие вещи, как (не настоящие имена методов или подписи):

• Копирование файлов:
  • CopyFile
  • DecryptAndCopyFile
• Файл настроек XML:
  • GetSpecificXMLValue (запрашивает значение в файле настроек XML)
  • SetSpecificXMLValue
  • DeleteSpecificXMLValue
• Создание каталогов
• Получение меток времени в виде строк (`return DateTime.Now.ToString (" yyyyMMddHHmmss ");`)
• Различные строковые функции для передаваемых параметров
• Запись в лог-файлы.
• Проверка переданного строкового параметра, если он содержит только элементы в белом списке (белый список представляет собой «только для чтения» частный список, которому присваивается значение в конструкторе.)

В настоящее время все другие проекты в решении имеют ссылку на этот проект, и они предоставляют доступ к классу:

namespace Us.OtherProjects
{
   public class clsCommon : Us.Common.clsCommon
   {}
}

namespace Us.OtherProjects
{
   public static class clsMain
   {
         public static clsCommon CommonClsClassReferenceForGlobalUsage = new clsCommon();
         .
         .
         .
   }
}

namespace Us.OtherProjects
{
   public class clsOtherClass
   {
      .
      .
      .
         private void someMethod()
         {
            string something = clsMain.CommonClsClassReferenceForGlobalUsage.Foo();
         }
      .
      .
      .
   }
}

Что вы думаете о том, чтобы сделать этот класс статическим, или, может быть, синглтоном, описанным Джоном Скитом здесь ?

Answer 1

Когда я слышу слова Common, Manager, Helper, я сразу думаю о запахе кода. Нет ничего проще, чем назвать класс без реального значения и просто скрыть внутри огромный код. Обычно это происходит, когда разработчик слишком подвержен процессуальному программированию.

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

---

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

---

То есть класс, который управляет вещами, не должен называться SomethingManager? Я не согласен в этом конкретном случае

Есть случаи, когда это может быть уместно. Но, как я понимаю, «XManager» просто говорит вам, что этот класс «Manager» работает с классом «X» и «управляет» чем-то, что должно означать «управление». Помощники помогают с чем-то. Что именно? Кто знает - надо проверить код. «Общее» еще более расплывчато. Видел все виды вещей в таких классах / пространствах имен / проектах (доступ к данным, безопасность и связанные с пользовательским интерфейсом вещи, связанные с логикой бизнес-домена).

---

Хммм ... так что, может быть, пространство имен Us.Common {public (static?) Class Strings {} public (static?) Class Files {} public (static?) Class Settings {}} Мнения об этой архитектуре меняются? Еще раз, я заинтересован в удобстве обслуживания и удобстве использования, пожалуйста.

Возможно, вам будет полезен этот пост . Согласно этому - это Logical cohesion в вашем случае.

Answer 2

Критерий здесь состояние . Если ваш класс является просто контейнером для независимых функций (например, CopyFile, GetTimeStamp), статический класс является наиболее логичным подходом. См. System.Math класс.

Однако у вашего класса есть конструктор, и я предполагаю, что он содержит некоторое состояние (имя файла config / log). Это требует Синглтона.

Глядя на список функциональных возможностей, я думаю, что вы должны изменить его на несколько классов. Некоторые могут (и должны) быть статичными. Используйте Singleton (s) для деталей, которые нуждаются в состоянии, таких как регистрация и настройка и т. Д.

Основная проблема дизайна, которую я вижу здесь, это наличие 1 класса, который выполняет Logging, Configuration, Formatting и много других вещей.