Служебные классы.. Хороший или Плохой?

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

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

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

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

Вопрос в том, действительно ли это стоит усилий? В некоторых системах ответ - да, но в других, особенно небольших, вероятно, нет.

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

Они хороши, если вы хорошо их спроектируете (то есть вам не нужно время от времени менять их подпись).

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

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

Думаю, будет хуже, если вы будете копировать / вставлять один и тот же служебный метод снова и снова.

Это видео Как разработать хороший API и почему это важно Джошуа Блох объясняет несколько концепций, которые следует учитывать при разработке API (это будет ваша служебная библиотека). Хотя он Как признанный архитектор Java, содержание применимо ко всем языкам программирования.

Я очень, очень стараюсь их избегать, но кого мы обманываем ... они проникают в каждую систему. Тем не менее, в приведенном примере я бы использовал объект URL, который затем предоставил бы различные атрибуты URL (протокол, домен, путь и параметры строки запроса). Почти каждый раз, когда я хочу создать служебный класс статики, я могу получить больше пользы, создав объект, который выполняет такую ​​работу.

Подобным образом я создал множество настраиваемых элементов управления которые имеют встроенную проверку для таких вещей, как проценты, валюта, номера телефонов и тому подобное. До этого у меня был служебный класс Parser, в котором были все эти правила, но он делает его намного более чистым, если просто разместить элемент управления на странице, который уже знает основные правила (и, следовательно, требует только бизнес-логики ]

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

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

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

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

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

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

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

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

Но в то же время вы не можете избежать утилит, они иногда требуются.

В этом случае я думаю, что все в порядке.

К вашему сведению, есть класс system.web.httputility, который содержит много распространенные утилиты http, которые могут оказаться полезными.