接口应该放在单独的包装中吗？[关闭]

我是一个刚开始从事大型项目的团队的新手，该项目具有许多组件和依赖项。对于每个组件，都有一个interfaces包装，用于放置该组件的暴露接口。这是一个好习惯吗？

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

放置接口和实现都是司空见惯的事，这似乎不是问题。

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

以java.util包装为例：

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

此外，Javadocs旨在在这些条件下很好地工作，因为当显示包的内容时，它将文档分为接口和类视图。

除非有大量的接口，否则仅具有用于接口的软件包实际上可能有点多余。但是仅仅为了这样做，将接口分成自己的程序包听起来是一种不好的做法。

如果需要将接口名称与实现区别开来，则可以使用一种命名约定来使接口更易于识别：

• 在接口名称前添加I。.NET框架中的接口采用了这种方法。可以很容易地说出这IList是列表的接口。

• 使用-able后缀。这种方法是Java API中经常看到，比如Comparable，Iterable和Serializable仅举几例。

对于任何语言，将它们放在同一程序包中都可以。重要的是暴露给外界的东西，以及它从外部看的样子。没有人会知道或不在乎实现是否在同一程序包中。

让我们看一下这个特定实例。

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

因此，这没有规则的味道，它没有充分的理由：它是基于公开可见的内容来做出决定，而该决定不会对公众可见内容产生任何影响。

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

在许多框架中，例如OSGi，您几乎都必须这样做。我认为这促进了在包装而非罐子级别的松耦合。

将接口放在不同包中的一个论据是，创建可以分发给产品或服务使用者的“ api”罐子更容易。完全可以通过接口和实现一起执行此操作，但是如果它们位于不同的程序包中，则编写脚本更容易。

《实用软件工程：案例研究方法》一书提倡将接口放在单独的项目/程序包中。

本书所讨论的PCMEF +体系结构具有以下原则：

1. 向下依赖原则（DDP）
2. 向上通知原则（UNP）
3. 邻居通讯原理（NCP）
4. 显式关联原则（EAP）
5. 循环消除原理（CEP）
6. 类命名原则（CNP）
7. 熟人打包原则（APP）

原则3和原则7的说明解释了为什么这是一个好主意：

邻居通信原理要求程序包只能与其邻居程序包直接通信。该原理确保系统不会分解为互通对象的不可压缩网络。为了执行该原则，在非相邻对象之间传递的消息使用委托（第9.1.5.1节）。在更复杂的场景中，可以使用相识软件包（第9.1.8.2节）来对接口进行分组，以帮助协作进行远处的软件包。

熟人打包原则是邻居沟通原则的结果。相识包由对象（而不是具体对象）传递给方法调用的参数的接口组成。这些接口可以在任何PCMEF软件包中实现。这有效地允许非相邻包之间的通信，同时将依赖项管理集中到单个相识包。9.1.8.2节解释了对熟人包的需求，接下来将在PCMEF上下文中再次讨论。

看到此链接：http : //comp.mq.edu.au/books/pse/about_book/Ch9.pdf

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

我们在我工作的地方这样做（即：将接口放在一个程序包中，而将实现放在另一个程序包中），而我们得到的主要好处是，我们可以轻松地在实现之间进行交换。

我没有太多的Java经验，但是我喜欢在C＃/。NET中将其作为一种好习惯，因为它允许将来扩展，在这种扩展中，带有实现接口的具体类的程序集可能不会一直分发到客户，因为它们由中间人工厂代理或在Web服务场景中跨线代理。

我通常将接口与实现放在一起，但是我可以有点明白为什么您可能希望将它们分开。举例来说，某人想根据您的接口重新实现类，那么他们需要在实现中添加jar / lib / etc，而不仅仅是接口。将它们分开，您只需要说“这是我对该接口的实现”即可完成。就像我说的，不是我做什么，但我可以有点明白为什么有些人会想要。

我正在做一个项目，由于以下原因，它对我来说效果很好：

• 与不同类型的Map或Set相比，单独打包的接口和实现用于不同的用例。没有理由只为树提供一个包（java.util.tree.Map，java.util.tree.Set）。它只是一个标准的数据结构，因此将其与其他数据结构放在一起。但是，如果您要处理的益智游戏具有非常简单的调试界面和漂亮的生产界面，则作为其前端的一部分，您可能会拥有com.your.app.skin.debug和com.your.app .skin.pretty。我不会将它们放在同一个程序包中，因为它们会做不同的事情，而且我知道我会诉诸一些SmurfNamingConvention（DebugAttackSurface，DebugDefenceSurface，PrettyAttackSurface等）为两个人创建一些非正式的命名空间（如果它们位于同一程序包中）。

• 对于查找单独程序包中的相关接口和实现的问题，我的解决方法是为程序包采用命名配置。例如，我可以将所有接口都放在com.your.app.skin.framework中，并且知道与包树相同级别的其他包是实现。缺点是这是非常规惯例。老实说，我将在6个月的时间内看到此约定的效果：)

• 我没有虔诚地使用这种技术。有些接口仅在特定的实现中有意义。我不会将它们放在框架包中。在某些程序包中，我看起来好像不会创建40个不同的实现类，因此不必理会。

• 我的应用程序使用guice并具有很多接口。

程序设计的问题通常涉及利弊，没有一个适合所有人的答案。就像为什么您会在小型200行程序中使用此技术？考虑到我的其他架构选择，对于我的特定问题，这对我来说很有意义。:)

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

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

将它们放在反映您的项目的程序包中。如果接口和实现属于同一项目，则可以将它们组合在一起，这很正常，但是如果您正在编写API，那么其他人可能会选择与其项目相关的软件包名称。

通常，如果是用于同一项目，那么将接口与其impls放在单独的程序包中不会带来任何好处。如果变得杂乱无章，则可能有其他软件包命名问题，而与接口的布置无关。

我认为必须注意，对于OSGi框架，最好将它们放在不同的程序包中，以便您可以轻松地导出整个程序包，同时隐藏实现程序包。

有很多充分的理由将接口与实现放在单独的程序包中。例如，您可能想使用支持Dependency Injection的容器在运行时连接必要的实现，在这种情况下，只需在构建时提供接口，并在运行时提供实现即可。或者，您可能希望在运行时提供多个实现（例如，使用模拟实现进行测试）或特定版本的多个版本（例如，用于A / B测试等）。对于此类使用案例，将接口和实现分开打包更为方便。