Entwerfen von Java-Schnittstellen mit normal klingenden Namen, die mit anderen Paketen "gut spielen"

Question

Ich möchte eine Schnittstelle mit dem Namen Tag in einem Java-Paket, an dem ich arbeite, definieren, bin aber zögerlich, einen solch klingenden Namen zu verwenden wegen des Kollisionsproblems. (Sie können z. B. nur eine Klasse oder Schnittstelle mit einem bestimmten Namen importieren; falls es mehrere gibt, die denselben Namen haben, können Sie den Import für einen von ihnen verwenden, aber den Rest müssen Sie explizit mit dem gesamten Paketnamen referenzieren) zB com.yoyodyne.games.outdoors.Tag)

Ich habe auch keinen wirklich detaillierten Namen dafür (es soll ein Tag wie die Tags in StackOverflow-Posts oder anderen Online-Websites darstellen); Am nächsten kommt vielleicht TaxonomyTag.

Gibt es Strategien, um damit umzugehen? Der einzige, den ich mir vorstellen kann, ist eine statische Klasse (wie Collections) zu definieren, die eine öffentliche Schnittstelle Tag, z.B. wenn ich es Taxonomy nenne, dann kann ich Taxonomy importieren und auf Tag als Taxonomy.Tag verweisen - aber das klingt nicht viel hilfreicher.

edit: ein weithin bekanntes Beispiel für diese Kollision ist ca.odell.glazedlists.matchers.Matcher und java.util.regex.Matcher, die ein Schmerz ist, wenn Sie reguläre Ausdrücke mit der GlazedLists Bibliothek zu verwenden versuchen.

Answer 1

Ich sehe kein Problem mit der Benennung der Klasse Tag. Ihr Paketname macht es universell einzigartig und das ist einer der Zwecke von Paketen - Namenskonflikte aufzulösen.

Sogar innerhalb der Java-API gibt es mehrere Klassen mit demselben Namen: java.util.Date, java.sql.Date zum Beispiel. Wenn Sie beide in Ihrem Code benötigen, verwenden Sie den vollständig qualifizierten Namen.

Answer 2

Ich würde nicht wirklich damit beschäftigt sein.

Worüber Sie besorgt sein sollten, ist, wie gut Ihr Klassen-/Interface-Name mit dem übereinstimmt, was der Code tatsächlich tut. Wenn Tag kurz und bündig beschreibt, was die Klasse/Schnittstelle macht und/oder modellieren soll, dann ist das ein großartiger Name.

Ich kann nicht wirklich die Situation sehen, in der Sie diesen Tag Typ in der gleichen Klasse zusammen mit anderen Tag Typen verwenden würden, die in verschiedenen Paketen deklariert sind. Aber, wenn Sie müssen, dann ist es nicht so ein Schmerz, sich auf die anderen Tag Typen durch ihren voll qualifizierten Namen zu beziehen.

Ich glaube, dass, wie gut Sie etwas benannt haben, größer ist als Dinge bequem zu machen.

Answer 3

Die beste Strategie ist es, Klassen zu schreiben, die eine Sache gut machen. Diese Klassen benötigen ein Minimum an Importen, sodass Sie Importanweisungen reduzieren können.

Ich suchte nach Standard-Tag-Schnittstellen; fand einen in java.swing..html, einen weiteren tief in der Servlet-API und einen weiteren in der Tapestry-Bibliothek. Ich bin mir sicher, dass Ihre Klasse nicht direkt eine dieser (oder ähnliche APIs) verwenden sollte, damit Sie keine Angst vor Namespace-Verschmutzung haben.

Eine andere Lösung besteht darin, das Tag mit dem Objekt zu versehen, auf dem es verwendet wird. Z.B. ArtikelTag. Aber Sie müssen den Objektnamen sorgfältig auswählen. Oder Sie können es jederzeit später umgestalten.

Answer 4

Wie viele Leute werden diese Klasse verwenden? Wenn es eine allgemeine Bibliothek sein soll, würde ich mit einem weniger generischen Namen gehen, um Kollisionen zu vermeiden. Wenn es nur Sie sind, und Sie wirklich nicht in den sauren Apfel beißen und mit voll qualifizierten Namen für jetzt gehen.

Wenn es ein Problem wird, bevor Sie das Paket freigeben, refactor es einfach auf einen neuen Namen.

In ähnlichen Situationen habe ich einen alternativen Namen für kurze Klassennamen gefunden, weil ich FQNs hasse. Sogar etwas wie JasonSTag kann als vorübergehende Lösung funktionieren; Gib es einfach nicht so raus. Oft werde ich nach der Hälfte der Implementierung einen besseren Weg finden, um die Klasse zu beschreiben, etwas Beschreibenderes als "Tag".

Answer 5

Im Allgemeinen ist die Anzahl der Konflikte, selbst bei "normal" klingenden Namen, gering. Ich habe im Kontext des Pakets einen aussagekräftigen Namen gewählt.

Do not somethiong "albern" wie Präfix es mit dem Firmennamen, zB: YoYoDyneTag.

Answer 6

Es ist in letzter Zeit aus der Mode gekommen, Adjektive/Adverbien als Interface-Namen zu verwenden, aber in Ihrem Fall würde es nicht so schlecht klingen, wenn Sie 'Tagable' oder 'TaxonomyTagable' verwenden würden.

Answer 7

Dies ist nur ein Problem, wenn Sie mehr als eine Klasse mit demselben Namen in einer einzigen Klasse verwenden müssen. Beispiele: java.awt.List und java.util.List, java.util.Date und java.sql.Date.

Wenn Sie sich von den bereits in der Standard-Java-Laufzeitumgebung verwendeten fernhalten, werden Sie höchstwahrscheinlich kein Problem haben.

Was auch immer Sie tun - machen Sie den Namen Sie wählen eine gute und beschreibende - das gilt besonders für diejenigen in einer öffentlichen API. Du wirst für immer mit ihnen leben.

Answer 8

Sind Sie faul? Wenn Ihre Klasse Importe so verwendet, dass "Tag" von jemandem, der Ihren Code gerade liest, falsch interpretiert werden kann, dann lohnt es sich, trotz der Paketnamenskonvention an einen besseren Namen zu denken. Unterschätzen Sie nicht die Macht der Benennung - oder umbenennen, wie sich die Klasse ändert.