Идеальное имя для статического класса для различных функций

Какое имя является идеальным для моего статического класса, который имеет некоторые статические методы для обработки общих / общих функций, например, создание резервных копий, сохранение последних элементов и т.д. (Infact Misc items) в C #. Я хотел бы иметь Manager как суффикс имени класса (например: SaleManager (для обработки функций, связанных с продажами), ContatManager (для обработки функций, связанных с контактами)


c# naming-conventions classname
person Shyju    schedule 03.11.2009    source источник
comment
Думаю, вам стоит взглянуть здесь: stackoverflow.com/questions/1175481/   -  person R. Martinho Fernandes    schedule 03.11.2009
comment
См. Также stackoverflow.com/questions/1271254/   -  person Robert Harvey    schedule 03.11.2009

Ответы (10)


arrow_upward
28
arrow_downward

RefactorMeManager.

person Mathias    schedule 03.11.2009
comment
-1 Юмористический, но не особо поучительный - person Robert Harvey; 03.11.2009
comment
@ Роберт - Не поучительно? Я бы сказал, это был дзен. - person annakata; 03.11.2009

arrow_upward
11
arrow_downward

Вот несколько классов .NET Framework, которые выполняют эти типы операций:

  • System.Environment
  • System.Math
  • System.IO.File
  • System.IO.Directory
  • System.IO.Path
  • System.Runtime.InteropServices.Marshal

Как видите, процедуры сгруппированы по темам в классы, и ни к одному из классов не добавлены «Помощник» или «Утилиты». Вот несколько созданных мной классов, которые выполняют некоторые из этих вещей:

  • SymbolicMath (как класс Math, но для работы с символьными математическими выражениями)
  • BigIntegerMath (библиотека большой целочисленной арифметики с использованием типа System.Numerics.BigInteger - доказательство простоты, факторинг и некоторые другие вещи)
person Sam Harwell    schedule 03.11.2009

arrow_upward
4
arrow_downward

Оказывается, «Полезность» спорна, а «Математика» - нет. Казалось бы, название должно указывать на общую функциональность методов статического класса.

person Robert Harvey    schedule 03.11.2009

arrow_upward
3
arrow_downward

Если у вас есть класс Utility (или UtilityManager), в котором есть множество статических методов, это действительно антипаттерн, и его следует немедленно реорганизовать.

Однако есть такие вещи, как утилиты, и не следует отказываться от помещения их в отдельный класс Утилиты (мой личный фаворит). Да, это открывает дверь для всевозможных уродливых сценариев, и нужно держать бразды правления, или что-то еще, и все закончится там, и да, есть необходимость «продвигать» методы в свой собственный класс (обычно XXXHelper) если возникнет необходимость, но, тем не менее, я считаю класс Utilities полезной конструкцией, а не антипаттерном сам по себе. Выкройки все-таки рекомендация, а не религия :)

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

person SWeko    schedule 03.11.2009

arrow_upward
3
arrow_downward

Да здравствует internal static class Utils.

person Mau    schedule 10.07.2010

arrow_upward
2
arrow_downward

По моему общему мнению, не должно быть такого общего класса. В частности, электронная почта, скорее всего, расширится до чего-то большего, чем просто метод SendEmail (), и, откровенно говоря, new Email({to, subject, body}).Send() имеет гораздо больше смысла в объектно-ориентированном стиле.

person annakata    schedule 03.11.2009
comment
да. только для этого примера я упоминал об этом, убирая это из вопроса сейчас - person Shyju; 03.11.2009

arrow_upward
1
arrow_downward

Инструменты
Утилиты
Расширения (если вы поместите туда только методы расширения (C #))

person Omu    schedule 03.11.2009

arrow_upward
0
arrow_downward

UtilityManager ..?

person Chris    schedule 03.11.2009

arrow_upward
0
arrow_downward

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

person R. Martinho Fernandes    schedule 03.11.2009

arrow_upward
0
arrow_downward

Даже для статических классов (кстати, я предпочитаю суффикс XxxHelper) я бы придерживался парадигмы «Разделение проблем "и не будет смешивать разные утилиты в одном классе.

person Marc Wittke    schedule 03.11.2009