разработка Java-интерфейсов с обычными именами, которые «хорошо играют» с другими пакетами

Question

Я бы хотел определить интерфейс с именем Tag в пакете Java, над которым я работаю, но не решаюсь использовать такое название с обычным звучанием из-за проблемы коллизий. (например, вы можете импортировать только один класс или интерфейс с определенным именем; если существует более одного класса с одним и тем же именем, вы можете использовать импорт для одного из них, но для остальных вы должны явно указать полное имя пакета например, com.yoyodyne.games.outdoors.Tag)

У меня также нет более подробного названия для него (он должен представлять тег как теги в сообщениях StackOverflow или других онлайн-сайтах); самое близкое, о чем я могу подумать - это, возможно, TaxonomyTag.

Существуют ли стратегии для борьбы с этим? Единственное, о чем я могу подумать, это определить статический класс (например, Collections), который содержит открытый интерфейс Tag, например. если я назову это Taxonomy, тогда я смогу импортировать Taxonomy и обозначить тег как Taxonomy.Tag - но это звучит не намного полезнее.

edit: один широко известный пример этого столкновения - ca.odell.glazedlists.matchers.Matcher и java.util.regex.Matcher , который боль, если вы пытаетесь использовать регулярные выражения с библиотекой GlazedLists.

Answer 1

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

Даже в Java API существует несколько классов с одинаковыми именами: например, java.util.Date, java.sql.Date. Если вам нужно и то, и другое в вашем коде, используйте полное имя.

Answer 2

Вы ленивый? Если ваш класс использует импорт таким образом, что «тег» может быть неправильно истолкован кем-то, кто читает ваш код, даже на мгновение, тогда стоит подумать о лучшем имени, несмотря на соглашение об именах пакетов. Не стоит недооценивать силу именования или переименования при изменении класса.

Answer 3

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

Если перед выпуском пакета возникнет проблема, просто измените его имя на новое.

В подобных ситуациях я нашел какое-то альтернативное имя для коротких имен классов, потому что я ненавижу использовать FQN. Даже что-то вроде JasonSTag может работать как временное исправление; просто не отпускай это так. Часто на полпути реализации я найду лучший способ описать класс, более описательный, чем «Tag».

Answer 4

Это, как правило, является проблемой, если вам нужно использовать более одного класса с одним и тем же именем в одном классе. Примеры: java.awt.List и java.util.List, java.util.Date и java.sql.Date.

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

Что бы вы ни делали - выбирайте имя, которое вы выбираете, хорошим и описательным - это особенно касается тех, кто находится в публичном API. Ты будешь жить с ними вечно.

Answer 5

В последнее время вышло из моды использование прилагательных / наречий в качестве имен интерфейсов, однако в вашем случае это будет звучать не так плохо, если вы используете «Tagable» или «TaxonomyTagable».

Answer 6

Как правило, количество конфликтов, даже с «обычными» звучащими именами, невелико. Я бы выбрал осмысленное имя в контексте пакета.

Не делайте что-нибудь «глупое», как префикс с названием компании, например: YoYoDyneTag.

Answer 7

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

Я искал стандартные интерфейсы тегов; нашел один в java.swing..html, другой глубоко в API сервлетов, а другой в библиотеке гобеленов. Я уверен, что вашему классу не следует напрямую использовать один из этих (или похожих API), поэтому вы можете не бояться загрязнения пространства имен.

Другое решение заключается в добавлении тега к объекту, на котором он будет использоваться. Например. ArticleTag. Но вы должны тщательно выбрать название объекта. Или, во всяком случае, вы всегда можете изменить его позже.

Answer 8

Я бы не стал этим заниматься.

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

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

Я считаю, что то, как хорошо вы назвали что-то, важнее, чем удобство.