设计具有普通声音名称的Java接口，与其他软件包“很好地配合”

Question

我想在我正在处理的Java包中定义一个名为Tag的接口，但由于碰撞问题，我对使用这样一个普通的名称犹豫不决。 （例如，您只能导入一个具有特定名称的类或接口;如果有多个具有相同名称的接口，则可以对其中一个使用import，但其余部分必须使用整个包名称明确引用例如com.yoyodyne.games.outdoors.Tag）

我也没有更详细的名称（它应该代表像StackOverflow帖子或其他在线网站中的标签一样的标签）;我能想到的最接近的可能是TaxonomyTag。

是否有处理此问题的策略？我能想到的唯一一个是定义一个静态类（如Collections），它包含一个公共接口Tag，例如如果我将其称为Taxonomy，那么我可以导入Taxonomy并引用Tag as Taxonomy.Tag - 但这听起来不太有用。

编辑：此次碰撞的一个众所周知的例子是ca.odell.glazedlists.matchers.Matcher和java.util.regex.Matcher，如果您尝试将正则表达式与GlazedLists库一起使用，那将会非常痛苦。< / p>

Answer 1

我没有看到命名类Tag的问题。您的软件包名称使其具有通用唯一性，这是软件包的目的之一 - 解决命名冲突。

即使在Java API中，也有多个具有相同名称的类：例如java.util.Date，java.sql.Date。如果您的代码中同时需要两者，则使用完全限定名称。

Answer 2

有多少人会使用这门课程？如果它是一个通用库，我会使用一个不太通用的名称来避免冲突。如果它只是你，你现在真的不咬紧牙关并使用完全合格的名字。

如果在发布软件包之前它出现问题，只需将其重构为新名称。

在类似的情况下，我找到了一些短名称的替代名称，因为我讨厌使用FQN。即使像JasonSTag这样的东西也可以作为临时修复;只是不要那样释放它。通常在实施过程中，我会找到一种更好的描述类的方法，比“标签”更具描述性。

Answer 3

你是懒惰吗？如果你的类使用导入使得“Tag”可能被读取代码的人误解，即使是暂时的，那么考虑一个更好的名称是值得的，尽管包命名约定。不要低估命名的力量 - 或者在课程改变时重命名。

Answer 4

我真的不会关心这个。

您应该关注的是您的类/接口名称与代码段实际执行的匹配程度。如果Tag简洁地描述了类/接口的功能和/或模型的含义，那么我认为它是一个很棒的名字。

我无法真正看到您在同一个类中使用此Tag类型以及在不同包中声明的其他Tag类型的情况。但是，如果必须，那么通过其完全限定名称引用其他Tag类型并不是那么痛苦。

我相信你对某事物的命名有多好，而不是让事情变得方便。

Answer 5

最好的策略是编写能很好地完成一件事的课程。这些类确实需要最少的导入，因此您可以减少import语句。

我寻找标准的Tag接口;在java.swing..html中找到一个，在servlet API中找到另一个，在tapestry库中找到另一个。我相信你的班级不应该直接使用其中一个（或类似的API），所以你可能不会害怕命名空间污染。

其他解决方案是在tag上添加将要使用的对象。例如。 ArticleTag。但是你必须仔细选择对象名称。或者，无论如何，你总是可以在以后重构它。

Answer 6

一般来说，即使是“普通”的声音名称，冲突的数量也很少。我在包的上下文中选择了一个有意义的名字。

不要做某些“愚蠢”，比如用公司名称作为前缀，例如：YoYoDyneTag。

Answer 7

最近使用形容词/副词作为界面名称已经过时了，但是，如果你使用'Tagable'或'TaxonomyTagable'，你的情况听起来不会那么糟糕。

Answer 8

如果您需要在单个类中使用多个具有相同名称的类，则这只会成为一个问题。示例：java.awt.List和java.util.List，java.util.Date和java.sql.Date。

如果您远离标准Java运行时中已经使用过的那些，那么很可能没有问题。

无论你做什么 - 使你选择的名称都是一个好的和描述性的 - 这对于公共API中的人来说尤其如此。你永远和他们住在一起。