Соглашение о присвоении имен и структура для служебных классов и методов
Попробуйте это
Если вы хотите открыть изображение из URL браузера, используйте это
http://localhost:4200/assets/images/smile.jpg
2 ответа
Я считаю, существует континуум сложности, поэтому соответствующие организации . Далее следуют примеры, выбирайте в зависимости от сложности вашего проекта и ваших утилит и адаптируйтесь к другим ограничениям:
- Один класс (называемый Helper) с несколькими методами
- Один пакет ( называется помощник), с несколькими классами (называемыми XXXHelper), каждый класс с несколькими методами. В качестве альтернативы, классы могут быть разбиты на несколько не вспомогательных пакетов, если они подходят.
- Один проект (называемый вспомогательным), с несколькими пакетами (называемыми XXX), каждый пакет с ... В качестве альтернативы пакеты могут быть разбиты на несколько не вспомогательных пакетов, если они подходят.
- Несколько вспомогательных проектов (с разбивкой по уровням, по используемым библиотекам или иным образом) ...
На каждом уровне группировки (упаковка, класс):
- общей частью значения является имя имени группировки
- Внутренние коды больше не нуждаются в этом значении (поэтому их имя короче, более сфокусировано и не нуждается в сокращениях, оно использует полные имена).
Для проектов я обычно повторяю общее значение в названии суперпакета. Хотя это не мой предпочтительный выбор в теории, я не вижу в своей IDE (Eclipse), из какого проекта импортируется класс, поэтому мне нужно, чтобы информация была повторена. Проект фактически используется только как:
- единица отгрузки: некоторые материалы или продукты будут иметь банку, а те, которые ей не нужны, -
- , чтобы выразить зависимости: например, бизнес-проект не зависит от помощников веб-уровня; выразив это в зависимости от проектов, мы улучшили очевидную сложность, что хорошо для нас; или найдя такую зависимость, мы знаем, что что-то не так, и начинаем расследовать ...; также, уменьшая зависимости, мы можем ускорить компиляцию и сборку ....
- чтобы классифицировать код, чтобы найти его быстрее: только когда он огромен, я говорю о тысячах классов в проекте
Обратите внимание, что все вышеперечисленное относится к динамическому методы, а не только статические. Это на самом деле наша хорошая практика для всего нашего кода.
Теперь, когда я попытался ответить на ваш вопрос (хотя и в широком смысле), позвольте мне добавить еще одну мысль
(я знаю, что вы не просили об этом) .
Статические методы (кроме тех, которые используют статические члены класса) работают без контекста, все данные должны передаваться как параметры. Все мы знаем, что в ОО-коде это не является предпочтительным способом. Теоретически, мы должны найти объект, наиболее соответствующий методу, и переместить этот метод на этот объект. Помните, что совместное использование кода не должно быть статическим , оно должно быть только публичным (или видимым иным образом).
Примеры того, куда перемещать статический метод:
- Если этот параметр имеет только один параметр.
- Если имеется несколько параметров, выберите между перемещением метода на:
- параметр, который используется чаще всего: параметр с несколькими полями или методами, которые используются или используются условными выражениями (в идеале некоторые условные выражения будут удалены переопределением подклассов) ...
- один существующий объект, который уже имеет хороший доступ к нескольким параметрам.
- создайте новый класс для этой потребности неоценимо, когда мы хотим подкласс его, чтобы изменить алгоритм). Eclipse перемещает метод менее чем за минуту (со всеми проверками), и мы получаем гораздо больше, чем минуту, когда мы ищем какой-то код или когда мы больше не кодируем метод, который уже был закодирован.
Ограничения: некоторые классы не могут быть расширены, обычно потому, что они вышли из-под контроля (JDK, библиотеки ...). Я считаю, что это реальное вспомогательное оправдание, когда вам нужно поместить метод в класс, который вы не можете изменить .
Наша хорошая практика заключается в том, чтобы называть помощника именем расширяемого класса с суффиксом помощника. (StringHelper, DateHelper). Такое тесное соответствие между классом, в котором мы хотели бы видеть код, и помощником помогает нам найти этот метод за несколько секунд, даже без знания, написал ли кто-то еще в нашем проекте этот метод или нет.
Суффикс Helper является хорошим соглашением , поскольку он используется в других языках (по крайней мере, в Java, рельсы IIRC используют его).
Намерение вашего помощника должно быть передано именем метода и использовать класс только как заполнитель. Например, ParseCommaSeparatedIntegersFromString - плохое имя по двум причинам:
- слишком длинный, на самом деле
- он избыточен, в статически типизированном языке вы можете удалить суффикс
FromString, поскольку он выводится из сигнатуры
Что вы думаете о:
CSVHelper.parse(String)
CSVHelper.create(int[])
HTMLHelper.clean(String)
...