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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

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

Да, не вопрос об этом.

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

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