让我们将包变成模块系统！

使用构建系统将许多项目分为模块/子项目（ Maven ， Gradle ， SBT …）；编写模块化代码通常是一件好事。将代码分为构建模块主要用于：

隔离代码部分（减少耦合）
api / impl拆分
仅将第三方依赖项添加到代码的特定部分
具有相似功能的代码分组
静态检查一个模块中的代码仅使用其依赖模块（模块间依赖）中的代码

尽管有些人可能说它对于单独的编译也很有用，但我认为这并不重要（考虑一个项目时）。如今，构建工具非常聪明，可以找出需要重新编译的内容。

构建模块问题

我认为这种方法存在一些问题。首先，很难确定何时某个功能“足够大”以将其转换为构建模块。几门课就够了吗？还是您需要更多？严格来说，每个模块是否应该只有一种功能？但这会导致模块爆炸。等等。至少在我参与的项目中，这是讨论的共同主题，即构建模块的粒度应如何粗略。

其次，构建模块非常“繁重”。我想Maven最糟糕，您需要一个很大的xml来创建一个模块，其中包含许多样板（例如重复的组ID，版本号，父级定义）； SBT和Gradle更好，但是，这仍然是一项巨大的努力。需要创建一个单独的目录，整个目录结构（ src/main/... ， src/test/... ），更新构建配置等。总的来说，这很麻烦。

然后，当我们经常将漂亮的模块分开时，事实证明，要使其中两个模块相互协作，我们需要一个“通用”部分。然后，我们要么以一个blo肿的foo-common模块结束，其中包含不相关的类，要么是多个小型foo-foomodule-common模块；第二种解决方案当然可以，只是浪费时间进行设置。

最后，构建模块是您还必须命名的其他内容。包名称和类名称很可能已经反映了代码的作用，现在还需要在构建模块名称中重复（违反DRY）。

总而言之，我认为创建构建模块非常困难且耗时。程序员是懒惰的（这当然是一件好事），这导致设计不像它们可能的那么干净。是时候改变它了:)。

（另请参见我先前的模块博客。）

配套

Java，Scala和Groovy已经有一个用于对代码进行分组的系统：程序包。但是，当前包仅是字符串标识符。除了一些非常有限的可见性选项（在Java中为package-private，在Scala中为package-scoping）之外，软件包没有语义。因此，我们有几个级别的分组代码：

项目
构建模块
包
类

如果我们将2.和3.合并在一起会怎样？为什么不应该使用软件包来创建模块？

包作为模块？

让我们来看看将包扩展为模块需要做什么。显然，我们需要做的第一件事是将一些元数据与每个模块相关联。已经有一些机制（例如，通过package-info.java上的注释），或者这可能是Scala中软件包对象的扩展-可以混入某些特征，或覆盖val 。

什么样的元数据？当然，我们不想将整个构建定义移到软件包中。但是让我们分开关注 –构建定义应该定义如何构建项目，而不是模块依赖项。然后，在模块的元数据中定义的第一件事就是对第三方库的依赖。这样的定义可能只是符号，它将被绑定到构建定义中的具体版本。

例如，我们将指定包“ foo.bar.dao ”取决于“ jpa ”库。然后，构建定义将包含从“ jpa ”到Maven工件列表的映射（例如hibernate-core，hibernate-entitymanager等）。而且，如果这种依赖关系可以传递到子包，则可能最有意义。因此，定义全局库将意味着增加对根包的依赖。

附带说明一下，通过扩展Scala的包对象，甚至可以将其设置为类型安全的。包对象可以实现特征，其中要覆盖的值之一可以是第三方依赖项符号的列表。符号本身可以包含在根包中定义的Enumeration中；这可以使诸如“根据jpa查找所有模块”之类的事情在IDE中进行简单的用法搜索。

第二步也是使用此机制定义模块间的依赖关系。在包的元数据中，可以定义其他包的列表，从中可以看到代码。这遵循当前使用的构建模块的方式：每个模块都包含可访问的项目模块的列表。（另一个Scala旁注：由于包对象将实现特征，因此这意味着定义具有给定类型的对象列表。）

进一步讲，我们可以指定api和impl类型包。默认情况下，可以从其他软件包访问Api型的。另一方面，如果未明确将Impl类型的程序包指定为依赖项，则无法访问它们。

在实践中看起来如何？ Scala中的一个非常粗糙的草图：

package foo.user// Even without definition, each package has an implicit package object 
// implementing a PackageModule trait ...
package object dao { // ... which is used here. The type of the val below is // List[PackageModule].override val moduleDependsOn = List(foo.security, foo.user.model) override val moduleType = ModuleType.API// FooLibs enum is defined in a top-level package or the build systemoverride val moduleLibraries = List(FooLibs.JPA) 
}

重构

重构是日常活动；但是，重构模块通常是一项艰巨的任务，偶尔需要处理一次。应该是这样吗？如果将程序包扩展到模块，则重构模块将与移动和重命名程序包相同，另外还需要更新元数据。这将比现在容易得多，我认为这将导致更好的总体设计。

建立系统

上面的内容显然意味着构建系统需要做更多的工作–很难确定模块列表，构建顺序，要创建的工件列表等（顺便说一句，如果要为一个程序包创建一个单独的jar，可以也是元数据的一部分）。此外，还需要进行一些验证-对于循环依赖关系，或试图以错误的方式限制可见性。

但是后来，人们做了比这更复杂的软件

拼图？

您可能会说，这与项目Jigsaw重叠，后者将在Java 9中（或不是）中出现。但是，我认为Jigsaw的目标范围不同：项目级别的模块。因此，一个拼图模块将是您的整个项目，而您将拥有多个（数十个）软件包模块。

名称“模块”在这里是重载的，也许名称“迷你模块”会更好，或者非常谦虚地“正确地打包”。

底线

我认为，当前定义构建模块的方法太过困难且受限制。另一方面，将包装提升到模块将非常轻便。定义一个新模块与创建一个新程序包相同–简单得多。第三方库只能在需要的地方添加。少一件事。每个项目只有一个源树。

同样，这种方法将可扩展并可根据项目需求进行调整。无需花费太多精力就可以定义细粒度模块或粗粒度模块。甚至更好的是，为什么不创建两个模块呢？模块可以嵌套并在另一个模块之上构建。

现在…唯一的问题是实现并添加IDE支持;）