Хорошо ли иметь класс «Utils» в вашем программном проекте?

Question

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

То, что я есть, я помещаю все эти вспомогательные функции как статической функции в пределах одного класса с именем «Utils»

https://github.com/yccheok/jstock/blob/master/src/org/yccheok/jstock/gui/Utils.java

Это хорошая практика? Будут ли вещи неуправляемы, когда количество функций растет все больше и больше?

Answer 1

Его абсолютно лучшая практика! вы не хотите смешивать все эти служебные функции с остальной бизнес-логикой приложения. Однако, поскольку ваши файлы utils и/или классы растут, рекомендуется группировать их в соответствии с предоставляемой ими функцией.

Например, в веб-приложении вы можете создать такую ​​структуру пакетов.

org.sample.web.model 
org.sample.web.utils 
org.sample.web.validators 
org.sample.web.validators.utils 

Answer 2

Я согласен с комментарием Майка. Я использую C#, но аналогичную реализацию. У меня есть проект утилиты, который я сохраняю в тайне, а затем просто бросаю DLL в новый проект. Таким образом, как ошибки/изменения происходят, я могу обновлять проекты, просто заменяя DLL.

Я занимаюсь отдельным классом для различных областей применения, как предположил Майк в своем комментарии.

Answer 3

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

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

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

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

Это хорошая практика?

Нет, не в долгосрочной перспективе, хотя это полезно, когда делается временно.

Будут ли вещи расти неуправляемыми, когда количество функций становится все больше и больше?

Да, не вопрос.

Answer 4

Класс полезности (или пакет классов) очень полезен. Обычно я обычно разделяю свои утилиты по функциональности на классы, поэтому у меня могут быть FileUtils, DatabaseUtils и т. Д.

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

Answer 5

Моя практика состоит в том, чтобы иметь как *Utils клады, так и *Helper классы. Первый содержит многократно используемые статические функции (для Java и PHP), которые не связаны друг с другом, где последние являются многократно используемыми логиками приложений/доменов - нестационарными методами и обычно с зависимостями с другими службами/компонентами/менеджерами.

Вот несколько правил, которые я применяю, прежде чем создать метод или *Utils класса:

1. ли сам язык уже поддерживает его?
2. Поддерживает ли Apache Commons? (или некоторые другие общие библиотеки - потому что кто-то мог написать что-то, что делает это лучше вас)
3. Как сделать его многоразовым (нейтральным по проекту/приложению), чтобы мои другие проекты могли его использовать?
4. Как это назвать? (Да, он всегда должен быть отнесен к категории и разделен, потому что эти классы в конечном итоге будут расти, и вы можете потерять контроль над ними, когда больше разработчиков добавят к нему больше методов.)

Answer 6

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

Answer 7

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

http://sourcemaking.com/antipatterns/the-blob

Answer 8

Это хорошая практика?

В большинстве случаев я использую этот способ.

Как и все объектно-ориентированное программирование, вы должны стремиться к максимальной сплоченности, минимальному сцеплению.

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

Answer 9

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

Для примера возьмем псевдо-фиктивный класс StringUtils. У вас могут быть сотни методов кодирования/декодирования для разных схем, трансформаций случаев, обработки пробелов и т. Д. Лучшим подходом, я думаю, является использование шаблона стратегии для обработки этих преобразований, что потенциально могло бы даже позволить возможность клиента код, вводящий новые преобразования без необходимости редактирования/перекомпиляции исходного кода. Вы получаете более мощную, гибкую и удобную систему.

Answer 10

Если это не менее статические, то это имеет смысл в классе Util. Это легко! Сцепление и сцепление предназначены для того, чтобы сделать вашу жизнь проще, это явная ситуация, в которой они этого не сделают, поэтому я предлагаю просто держать ее в пути.

Answer 11

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

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