1

将我的公共接口放入他们自己的包中是否可以（仅适用于我的组织）。

例如

com.example.myprogram - contains all normal code

com.example.myprogram.public - contains public accessible interfaces

com.example.myprogram.abstract - contains abstract classes

这是好事还是坏事，有什么坏处吗？

4

4 回答 4

3

我根本不喜欢这种做法。您应该根据功能对抽象和具体的类以及接口进行分组。

以 Java API 为例。Sun 是否将 Collections 接口与实现分开？不，Sun 的做法并不总是最好的指导，但在这种情况下，我同意。

不要这样做。

于 2010-03-06T16:55:15.403 回答
2

我可以建议你两种常见的方法：

  1. 如果你真的认为你的接口将来可以有更多的实现（即你正在研究 API），那么将它们移动到一个单独的模块并在那里创建一个名为“core”的特殊包，例如。( com.example.myprogram.core)。实现应该在对应的包中（如com.example.myprogram.firstimpl）。

  2. 如果您只有 1 个实现，那么让所有接口都在com.example.myprogram包中，所有具体类都在in com.example.myprogram.impl包中。

于 2010-03-06T16:03:41.983 回答
0

我不认为这是一种不好的做法，但是您可能想考虑作为按逻辑功能而不是语法定义组织您的东西的替代方法，以便给定功能接口/抽象类/普通代码单元的所有代码都进入同一个包。这是模块化编程的原则之一。

话虽如此，根据项目的大小，可能需要将所有接口（但仅限于那些接口）放在一个单独的包中，如果你有一个纯基于组件的插件架构（这样其他模块只知道接口和实际实现以某种方式动态注入）。

于 2010-03-06T16:02:11.510 回答
0

公共接口是系统模块或系统之间的正式合同。正因为如此，将它们与代码的其余部分隔离开来使它们脱颖而出是有意义的。

例如，在我工作过的系统中，系统的服务器和客户端组件之间的所有公共接口都放置在一个特殊的系统模块中（毫不奇怪，称为“api”）。这有许多理想的效果，其中包括： - 从语义上讲，如果您需要有关如何进行通信的任何类型的信息，您知道在哪里查找 - 您可以单独对 api 模块进行版本控制，这在您不需要时特别有用不想要一个移动的目标，即你签署一份合同来交付一个支持“api v.1.1”的应用程序，而不是在别人改变界面并要求你适应你的一方时不断地玩catch

这并不意味着您不应该在子包中进一步组织它们以区分它们的用途。:)

总之，通过将接口与代码库的其余部分分离，您正在做正确的事情，尽管根据您的特定需求，您最好更进一步，将接口隔离在单独的系统模块中。

于 2010-03-06T16:03:35.423 回答