如何对不同项目中的关联类进行排序
我遇到一种情况，我正在重构旧代码，拆开一个旧的怪物项目并将其（出于各种原因）拆分为更小的子项目。 一个项目最终将包含大部分接口，而它们的相关实现位于另一个项目中，并且我不确定设置包结构的最佳方法。
我应该去吗
org.company.interfaceproject.util.InterfaceClass 和
org.company.implementationproject.util.ImplementationClass
或
org.company.project.util.InterfaceClass 和
org.company.project.util.ImplementationClass
其中第一个实现的优点是指出文件属于哪个项目，而第二个实现则不会混合文件位于不同的事实项目。
我想这里没有对与错，但我很好奇是否有人对此事有任何看法。
I have a situation where I'm refactoring old code, taking apart an old monster project and splitting it (for various reasons) into smaller sub projects. One project is going to end up containing mostly interfaces while their associated implementations are in another project, and I'm not sure about the best way of setting up the package structure.
Should I go for
org.company.interfaceproject.util.InterfaceClass and
org.company.implementationproject.util.ImplementationClass
or
org.company.project.util.InterfaceClass and
org.company.project.util.ImplementationClass
where the first implementation has the advantage of pointing out to which project the files belong, while the second on doesn't mix in the fact that the files are in different projects at all.
I guess there is no right and wrong here, but I'm curious if anybody has any opinions on the matter.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，您只需要想出一个命名约定。 通常，两者的结合适合我们公司以避免歧义。 例如，假设您有一个接口：
然后，我们将使用以下内容作为由 spring 依赖项连接或具有 spring 依赖项的实现类：
这则具有两个观点中最好的：
Yes you need to just come up with a naming convention. Usually a combination of both has suited our company to avoid ambiguity. For example, say you had an interface:
Then, we would use the following for the implementation class that was wired by, or had, spring dependencies:
This then has the best of both viewpoints:
UserService, and still distinguishable even when both packages are imported.两者各有优点。 这最终取决于您对该项目的意图。 如果您的目的是最终创建接口的替代实现，那么选择选项 1 可能更有意义。如果这是接口的唯一实现，选项 2 会更合理。
Both have merits. It ultimately depends on you intentions for the project. If your intent is to eventually create alternate implementations of the interfaces it may make more sense to go with option 1. If this will be the only implementation of the interfaces option 2 would be more reasonable.
Sun 有命名约定。 对于包裹：
所以我更喜欢指定项目名称的第二个选项。 或者我会像这样合并两者：
Sun has Naming conventions. For packages:
So I would prefer the second option where you specify project name. Or I would merge both like this:
如果可以的话，您应该将接口类放入单独的插件/包中。
当您使用接口时，大多数时候您都会有多个该接口的实现。
我更喜欢选项 1
If you can you should put the interface clases into a seperate plugin/package.
When you use interfaces you most of the time will have more than one implementation of this interface.
I would prefer option 1
大多数人同意克林顿的观点。
最终，就 Java 而言，每个包名称都是一个孤岛，但根据构建时组装的内容来隔离事物可能会很方便，如下所示：
大多数情况下，这可以使您的 ant 文件集保持简单。 请注意，即使由于构建方式或其他原因，源文件的布局完全不同，这也适用。 我要说的唯一一件事是小心不要在多个源目录中获取相同的包！ 这可能很丑陋，而且很容易意外发生。
因此，除非这种想法促使您创建单独的高级包，否则我喜欢将实现包放在接口包中的风格，为 impl 包指定一个表明其专业化的名称，并命名实现
FooImpl。 您几乎从不需要导入多个实现，但有时您确实希望同时导入接口和 impl，在这种情况下，如果它们具有相似的名称，那就太好了。Mostly agree with Clinton.
Ultimately, each package name is an island as far as Java is concerned, but it can be handy to segregate things according to what gets assembled with what at build time, as in:
Mostly this keeps your ant filesets simple. Note that this applies even if the layout of source files is quite different, due to the way things get built or whatever. The only thing I would say is be careful not to get the same package in more than one source directory! That can be ugly and is easy to do by accident.
So unless that kind of thinking pushes you to create separate high-level packages, I like the style of putting the implementation package inside the interface package, giving the impl package a name that suggests how it is specialized, and of naming the implementation
FooImpl. You almost never need to import multiple implementations, but you occasionally do want to import both the interface and impl, and in that case it's nice if they have a similar name.