是否可以将我的公共接口放入他们自己的包中（仅适用于我的组织）。
例如
com.example.myprogram - contains all normal code
com.example.myprogram.public - contains public accessible interfaces
com.example.myprogram.abstract - contains abstract classes
这是好事还是坏事，有什么坏处吗？
【问题讨论】：
标签： java language-agnostic code-organization
我根本不喜欢这种做法。您应该根据功能对抽象类和具体类以及接口进行分组。
以 Java API 为例。 Sun 是否将 Collections 接口与实现分开？不。Sun 的做法并不总是最好的指导，但在这种情况下我同意。
别这样。
【讨论】：
我可以建议你两种常用的方法：
com.example.myprogram.core)。实现应该在对应的包中（如com.example.myprogram.firstimpl）。
如果你只有 1 个实现，那么让你的所有接口都在 com.example.myprogram 包和所有具体类 in com.example.myprogram.impl 包中。
【讨论】：
我不认为这是一种不好的做法，但是您可能想考虑作为一种替代方法来根据逻辑功能而不是语法定义来组织您的东西，以便给定功能单元的所有代码接口/抽象类/普通代码放在同一个包里。这是modular programming的原则之一。
这么说，根据项目的大小，可能需要将所有接口（但仅限于那些接口）放在一个单独的包中，如果您有一个纯基于组件的插件架构（以便其他模块只知道接口，实际的实现是以某种方式动态注入的）。
【讨论】：
公共接口是系统模块或系统之间的正式合同。因此，将它们与代码的其余部分隔离开来是有意义的。
例如，在我工作过的系统中，系统的服务器和客户端组件之间的所有公共接口都放置在一个特殊的系统模块中（毫不奇怪，称为“api”）。这具有许多理想的效果，其中包括： - 从语义上讲，如果您需要有关如何进行通信的任何类型的信息，您知道去哪里寻找 - 您可以单独对 api 模块进行版本控制，这在您不想要移动目标时特别有用，即您签订合同以交付支持“api v.1.1”的应用程序，而不是不断地在别人的时候玩catch改变界面，需要你适应自己的一面
这并不意味着您不应该在子包中进一步组织它们以区分它们的用途。 :)
总之，通过将接口与代码库的其余部分分离，您是在做正确的事情，尽管根据您的具体需求，您最好更进一步，将接口隔离在单独的系统模块中.
【讨论】：