网站开发模式有什么,自学电商还是去培训机构,微信公众平台网站建设新闻报道,乌克兰设计网站建设idea如何把包变为模块使用构建系统将许多项目分为模块/子项目#xff08; Maven #xff0c; Gradle #xff0c; SBT …#xff09;#xff1b; 编写模块化代码通常是一件好事。 将代码分为构建模块主要用于#xff1a; 隔离代码部分#xff08;减少耦合#xff09; … idea如何把包变为模块 使用构建系统将许多项目分为模块/子项目 Maven Gradle SBT … 编写模块化代码通常是一件好事。 将代码分为构建模块主要用于 隔离代码部分减少耦合 api / impl拆分 仅将第三方依赖项添加到代码的特定部分 具有相似功能的代码分组 静态检查一个模块中的代码仅使用其依赖模块模块间依赖中的代码 尽管有些人可能说它对于单独的编译也很有用但我认为这并不重要考虑一个项目时。 如今构建工具非常聪明可以找出需要重新编译的内容。 构建模块问题 我认为这种方法存在一些问题。 首先很难确定何时某个功能“足够大”以将其转换为构建模块。 几门课就够了吗 还是您需要更多 严格来说每个模块是否应该只有一种功能 但这会导致模块爆炸。 等等。 至少在我参与的项目中这是讨论的共同主题即构建模块的粒度应如何粗略。 其次构建模块非常“繁重”。 我想Maven最糟糕您需要大量的xml来创建一个带有大量样板文件的模块例如重复的组ID版本号父级定义 SBT和Gradle更好但仍然是一项巨大的努力。 需要创建一个单独的目录整个目录结构 src/main/... src/test/... 更新构建配置等。总的来说这很麻烦。 然后当我们将漂亮的模块分开时经常会发现为了使它们中的两个相互协作我们需要一个“通用”部分。 然后我们要么以一个肿的foo-common模块结束该模块包含不相关类的负载要么以多个小型foo-foomodule-common模块结束 第二种解决方案当然没问题只是浪费时间进行设置。 最后构建模块是您还必须命名的其他内容。 软件包名称和类名称很可能已经反映了代码的作用现在还需要在构建模块名称中重复违反DRY。 总而言之我认为创建构建模块非常困难且耗时。 程序员是懒惰的当然这是一件好事这导致设计不像它们可能的那么干净。 是时候改变它了:) 另请参见我之前有关模块的博客 。 配套 JavaScala和Groovy已经有一个用于对代码进行分组的系统程序包。 但是当前包仅是字符串标识符。 除了一些非常有限的可见性选项在Java中为package-private在Scala中为package-scoping之外软件包没有语义。 因此我们有几个级别的分组代码 项目 构建模块 包 类 如果我们将2.和3.合并在一起会怎样 为什么不应该使用软件包来创建模块 包作为模块 让我们来看看将包扩展为模块会怎样。 显然我们需要做的第一件事是将一些元数据与每个模块相关联。 已经有一些机制例如通过package-info.java上的注释或者这可能是Scala中软件包对象的扩展-可以混入某些特征或覆盖val 。 什么样的元数据 当然我们不想将整个构建定义移到软件包中。 但是让我们分开关注 –构建定义应该定义如何构建项目而不是模块依赖项。 然后在模块的元数据中定义的第一件事就是对第三方库的依赖。 这样的定义可能只是符号它将被绑定到构建定义中的具体版本。 例如我们将指定包“ foo.bar.dao ”取决于“ jpa ”库。 然后构建定义将包含从“ jpa ”到Maven工件列表的映射例如hibernate-corehibernate-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支持; 参考 让我们将包变成模块系统 来自我们的JCG合作伙伴 Adam Warski 网址为Adam Warski博客。 翻译自: https://www.javacodegeeks.com/2012/11/lets-turn-packages-into-a-module-system.htmlidea如何把包变为模块
