Java 接口应该放在单独的包中吗？

Should interfaces be placed in a separate package?

提问by kctang

I'm new to a team working on a rather large project, with lots of components and dependencies. For every component, there's an interfacespackage where the exposed interfaces for that component are placed. Is this a good practice?

我是一个团队的新手，正在处理一个相当大的项目，有很多组件和依赖项。对于每个组件，都有一个interfaces包，用于放置该组件的公开接口。这是一个好习惯吗？

My usual practice has always been interfaces and implementations go in the same package.

我通常的做法是将接口和实现放在同一个包中。

采纳答案by coobird

Placing both the interface and the implementation is common place, and doesn't seem to be a problem.

放置接口和实现是常见的地方，似乎不是问题。

Take for example the Java API -- most classes have both interfaces and their implementations included in the same package.

以 Java API 为例——大多数类都将接口及其实现包含在同一个包中。

Take for example the java.utilpackage:

以java.util包为例：

It contains the interfaces such as Set, Map, List, while also having the implementations such as HashSet, HashMapand ArrayList.

它包含诸如Set, Map,之类的接口List，同时还具有诸如HashSet,HashMap和 之类的实现ArrayList。

Furthermore, the Javadocs are designed to work well in those conditions, as it separates the documentation into the Interfacesand Classesviews when displaying the contents of the package.

此外，Javadoc 被设计为在这些条件下工作良好，因为它在显示包的内容时将文档分成接口和类视图。

Having packages only for interfaces may actually be a little bit excessive, unless there are enormous numbers of interfaces. But separating the interfaces into their own packages just for the sake of doing so sounds like bad practice.

除非有大量的接口，否则只为接口使用包实际上可能有点过分。但是为了这样做而将接口分成自己的包听起来是不好的做法。

If differentiating the name of a interface from an implementation is necessary, one could have a naming convention to make interfaces easier to identify:

如果需要区分接口的名称和实现，则可以有一个命名约定，使接口更容易识别：

• Prefix the interface name with an I.This approach is taken with the interfaces in the .NET framework. It would be fairly easy to tell that IListis an interface for a list.

• Use the -ablesuffix.This approach is seen often in the Java API, such as Comparable, Iterable, and Serializableto name a few.

• 使用I.作为接口名称的前缀。.NET 框架中的接口采用了这种方法。很容易说这IList是一个列表的接口。

• 使用 -able后缀。这种方法经常出现在 Java API 中，例如Comparable、Iterable、Serializable等等。

回答by Paul Sonier

Yes, it's a very good practice, because it allows you to publish the interface without publishing your specific implementation. That said, if you have no need to publish external interfaces, there's no problem with putting the interface definitions in the same package as the implementation.

是的，这是一个非常好的做法，因为它允许您在不发布特定实现的情况下发布接口。也就是说，如果您不需要发布外部接口，那么将接口定义与实现放在同一个包中是没有问题的。

回答by cjs

For any language, putting them together in the same package is fine. The important thing is what's exposed to the outside world, and how it looks from outside. Nobody's going to know or care if the implementation is in that same package or not.

对于任何语言，将它们放在同一个包中都可以。重要的是暴露在外部世界的东西，以及它从外面看起来的样子。没有人会知道或关心实现是否在同一个包中。

Let's look at this particular instance.

让我们看看这个特殊的例子。

If you have all public things in one package, and private things in another package that is not publicly exposed, the client of the library sees one package. If you move the private things to the package with the publicly exposed things, but do not expose them from within the package, the client sees exactly the same thing.

如果您在一个包中包含所有公共内容，而在另一个未公开的包中包含私有内容，则库的客户端会看到一个包。如果您将私有事物与公开暴露的事物一起移动到包中，但不从包内部公开它们，则客户端看到的内容完全相同。

Thus, this has the smell of a rule with no good reason: it's making a decision based on something being publicly visible without that decision having any effect on what's publicly visible.

因此，这有一种没有充分理由的规则的味道：它根据公开可见的内容做出决定，而该决定对公开可见的内容没有任何影响。

That said, if in any particular instance it seems like a good idea to split the interface and implementation in to separate packages, go right ahead and do that. Reasons for doing this that come to mind are that the package is huge, or you have an alternate implementation you might want to link in instead of the standard one.

也就是说，如果在任何特定情况下将接口和实现拆分为单独的包似乎是个好主意，请继续这样做。想到这样做的原因是包很大，或者您可能想要链接替代实现而不是标准实现。

回答by hhafez

We do this where I work (ie: put interface in one package and implementation in another) and the main advantage we get out of this is we can easily swap between implementations.

我们在我工作的地方这样做（即：将接口放在一个包中，将实现放在另一个包中），我们从中获得的主要优势是我们可以轻松地在实现之间切换。

回答by Jesse C. Slicer

I haven't much Java experience, but I like to do this as a good practice in C#/.NET because it allows for future expansion where the assemblies with the concrete classes which implement the interfaces may not be distributed all the way down to the client because they are proxied by a middleman factory or across the wire in a web service scenario.

我没有太多的 Java 经验，但我喜欢在 C#/.NET 中将其作为一种很好的做法，因为它允许未来的扩展，其中具有实现接口的具体类的程序集可能不会一直分布到客户端，因为它们由中间人工厂代理或在 Web 服务场景中通过网络进行代理。

回答by Cameron Pope

One argument for putting interfaces in different packages is that it is easier to create 'api' jars that can be distributed to consumers of your product or service. It's perfectly possible to do this with interfaces and implementations together, but simpler to script if they are in different packages.

将接口放在不同的包中的一个论点是，创建可以分发给您的产品或服务的消费者的“api”jar 更容易。将接口和实现一起使用是完全可能的，但如果它们在不同的包中，则编写脚本会更简单。

回答by Rog

Put them in packages that reflect your projects. It is fine and common to put interfaces and implementations together if they're part of the same project, but if you're writing an API, then someone else would likely be choosing a package name relevant to their project.

将它们放在反映您的项目的包中。如果接口和实现是同一个项目的一部分，那么将它们放在一起是很好且常见的，但是如果您正在编写 API，那么其他人可能会选择与他们的项目相关的包名称。

In general, if it's for the same project, I don't see any benefit in keeping the interfaces in a separate package from their impls. If it's getting cluttered, there may be other package naming issues, irrespective of the interface arrangement.

一般来说，如果它是用于同一个项目，我认为将接口与它们的实现放在一个单独的包中没有任何好处。如果它变得杂乱无章，则可能存在其他包命名问题，而与接口安排无关。

回答by javamonkey79

In many frameworks, such as OSGi, you almost have to. I think this promotes looser coupling, at the package instead of the jar level.

在许多框架中，例如 OSGi，您几乎必须这样做。我认为这促进了更松散的耦合，在包而不是 jar 级别。

回答by aberrant80

I prefer them in the same package. Feels pointless to create a package specifically for interfaces. This is especially redundant for teams that simply love their interface prefixes and suffixes (e.g. the "I", and "Impl" for Java).

我更喜欢它们在同一个包装中。专门为接口创建一个包感觉毫无意义。对于只喜欢接口前缀和后缀（例如 Java 的“I”和“Impl”）的团队来说，这尤其多余。

If there's a needs to publish a set of interfaces as public API, it makes more sense to keep them in an entirely separate project and create project dependencies instead. But it all boils down to preference and convenience of the situation I suppose.

如果需要将一组接口发布为公共 API，将它们保存在一个完全独立的项目中并改为创建项目依赖关系更有意义。但这一切都归结为我想的情况的偏好和便利。

回答by Matt_JD

I normally put Interfaces with the implementation however I can sort of see why you may want to keep them separate. Say, for instance, someone wanted to reimplement classes based upon your interfaces, they would need a jar/lib/etc with your implementation rather than just the interfaces. With them separate you could just say "Here's my implementation of that interface" and be done with it. Like I said, not what I do but I can sort of see why some might want to.

我通常将接口与实现放在一起，但是我可以理解为什么您可能希望将它们分开。比如说，有人想根据你的接口重新实现类，他们需要一个带有你的实现的 jar/lib/etc 而不仅仅是接口。将它们分开后，您可以只说“这是我对该接口的实现”并完成它。就像我说的，不是我做什么，但我可以理解为什么有些人可能想要。