Соглашение об именах и структура классов и методов полезности

Есть ли у вас какие-либо данные о том, как организовать и назвать классы утилиты?

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

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

Примеры:

ParseCommaSeparatedIntegersFromString( string )
CreateCommaSeparatedStringFromIntegers( int[] )
CleanHtmlTags( string )
GetListOfIdsFromCollectionOfX( CollectionX )
CompressByteData( byte[] )

Обычно соглашения об именах говорят вам назвать ваш класс как существительное. Я часто получаю много классов, таких как HtmlHelper, CompressHelper, но они не очень информативны. Я также попытался быть действительно конкретным, как HtmlTagCleaner, который обычно заканчивается одним классом для каждого метода утилиты.

Есть ли у вас идеи о том, как назвать и сгруппировать эти вспомогательные методы?

Ответ 1

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

Один класс (называемый помощником) с несколькими методами
Один пакет (называемый помощником) с несколькими классами (называемый XXXHelper), каждый класс с несколькими методами. Альтернативно, классы могут быть разделены в нескольких несерверных пакетах, если они подходят.
Один проект (называемый помощником) с несколькими пакетами (называемый XXX), каждый пакет с... В качестве альтернативы, пакеты могут быть разделены на несколько несерверных пакетов, если они подходят.
Несколько вспомогательных проектов (разделение по уровням, по используемой библиотеке или иным образом)...

На каждом уровне группировки (пакет, класс):

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

Для проектов я обычно повторяю общее значение в имени суперпаки. Хотя это не мой предпочтительный выбор в теории, я не вижу в своей среде IDE (Eclipse), из какого проекта импортируется класс, поэтому мне нужно, чтобы информация повторялась. Проект фактически используется только как:

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

Обратите внимание, что все вышеизложенное относится и к динамическим методам, а не только к статическим. Это на самом деле наша хорошая практика для всего нашего кода.

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

Статические методы (кроме тех, которые используют статические члены класса) работают без контекста, все данные должны передаваться как параметры. Мы все знаем, что в коде OO это не самый предпочтительный способ. Теоретически мы должны искать объект, наиболее соответствующий методу, и перемещать этот метод на этот объект. Помните, что совместное использование кода не должно быть статическим, оно должно быть общедоступным (или иным образом видимым).

Примеры перемещения статического метода:

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

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

Ограничения: некоторые классы не могут быть расширены, как правило, потому что они неконтролируемы (JDK, библиотеки...). Я считаю, что это реальное вспомогательное обоснование, когда вам нужно поместить метод в класс, который вы не можете изменить.

Наша хорошая практика заключается в том, чтобы называть помощника с расширением имени класса с суффиксом Helper. (StringHelper, DateHelper). Это близкое соответствие между классом, в котором мы хотим, чтобы код был и Помощник, помогает нам найти этот метод за несколько секунд, даже без знания, если кто-то из нашего проекта написал этот метод или нет.

Ответ 2

Суффикс Helper является хорошим соглашением, поскольку он используется на других языках (по крайней мере, в Java, используются рельсы IIRC).

Цель вашего помощника должна быть передана по имени метода и использовать класс только как заполнитель. Например, ParseCommaSeparatedIntegersFromString является плохим именем по нескольким причинам:

слишком долго, на самом деле
он избыточен, на статически типизированном языке вы можете удалить суффикс FromString поскольку он выводится из подписи

О чем вы думаете:

CSVHelper.parse(String)
CSVHelper.create(int[])
HTMLHelper.clean(String)
...