《java技巧：模块化编程的优点与实现原理概述》由会员分享，可在线阅读，更多相关《java技巧：模块化编程的优点与实现原理概述（4页珍藏版）》请在金锄头文库上搜索。
1、JAVA 技巧：模块化编程的优点与实现原理概述技巧：模块化编程的优点与实现原理概述2010 年 01 月 27 日 09:30本文是Rich Client Programming: Plugging into the NetBeans Platform（中文版译名为NetBeans 富客户端编程权威教程，Sun 中国技术社区推荐的 NetBeans 学习用书）英文版公开章节，即第二章的节选译文，章节名称为“模块化编程的好处”。通过阅读这一章节，读者们将对模块化编程的起源和实现原理产生初步的了解，并了解到模块化编程的优点。有关模块化编程的实现部分，本文着重介绍了 NetBeans 的情况。 分布
2、式开发分布式开发 闭门造车的软件开发时代早已过去。在嵌入式系统之外，几乎每一位开发者都需要依赖别人写的类库或框架。这种借助并复用他人提供的基础设施、框架以及类库的好处在于使自己能够专注于应用本身的逻辑当中。这样缩短了软件开发所需要的时间。 过去的几十年间，开源软件的兴起令类库的复用具有双倍的吸引力。我们现在有针对多种程序中的各种问题而诞生的现成解决方案，而获取这些解决方案不用花一文钱。开源产品起于 UNIX 内核，基础 C 类库和命令行工具，并通过 Web 服务器和 Web 浏览器延伸至 Ant，Tomcat，JUnit，Javacc 等 Java 工具领域而这种情况还有无限制发展的趋势。在编
3、写一个现代软件的过程中，集成工作的部分和创新的部分大致是对半分的。将可用的碎片捡起来并组合到一起是现代应用开发的主要工序。人们不再从零开始编写一切。人们在需要 HTTP 服务器的时候为他们的应用选择 Apache 或者 Tomcat，在需要数据库的时候选择 MySQL 或 PostgreSQL。应用软件将这些零碎部件粘连起来，并加入自己的逻辑。最终的成品是功能完备的、性能好的、并且在相当短的时间内开发出来的应用软件。 看看 Linux 版本是如何发行的。红帽的 Fedora，Mandriva，SUSE，还有 Debian，它们所包含的应用程序其实大致上差不多，而且都是同一群人写的。发布者不过是
4、简单的将它们打包，并提供“胶水”用于统一的安装。发行商往往只编写中央管理软件和安装软件，并提供一些质量保证，以确保所有选定的组件能够协同工作。这个过程对于Linux 的普及产生了相当理想的效果。有一个例子可以证明此模型的意义，那就是 Mac OS X：它其实就是个安装了一堆苹果插件的 FreeBSD Unix。对于这样的软件，需要注意的一个重点就是它创建的方式采用了一种分布式开发模型。软件的开发者和发行者可能完全不认识对方，也没有交流过，而他们往往也并不生活在同一个地域。 这种分布式开发有如下特征。第一，应用程序（或操作系统）的源代码不再处于某一个开发者完全的掌控之中。源代码被散布至世界各地。
5、毫无疑问，构建这样的软件与传统那种源代码完全在你家中的代码库的应用构建是完全不同的。 另外我们需要了解的是，也没有一个人对整个项目的时间表有完全的掌控。不单单是源代码，开发者们也遍布世界各地，并以他们自己的时间表工作。这种情况并不像听起来的那样不寻常或不靠谱。如果你曾经为超过五十人的项目制定过时间表，那么你一定会明白，对整个项目进程拥有“完全的掌控”最多只是一个安慰自己的幻想。你随时需要准备好抛弃某个特性，或是发布这个或那个组件的一个老版本。同样的模式也适用于分布式开发。 每个人都有这样一个权利：使用一个新版本或旧版本类库的自由。 使用外部库并使用它们组建应用程序，这意味着人们能够花费更少的时
6、间和精力创造更复杂的软件。代价则是，我们需要管理这些类库，确保它们的兼容性。这不是一个简单的任务。但是，对于如今高度复杂系统的组建，也没有其他既实用、性价比又高的开发模式了。 模块化应用程序模块化应用程序 针对分布式开发的挑战，其技术解决方案就是模块化。在一大块紧密耦合的代码中，每个单元都可能与其他单元进行直接的接口。而模块化应用则正相反，它由小块的、分散的代码块组成，每一块都是独立的。于是，这些代码块可以由不同的团队进行开发，而他们都有各自的生命周期和时间表。最终的成果则可以由另一个独立的个体，即发行者，进行集成。 对于 Java 而言，将一组类库放在 Java 类路径上并运行一个应用程序在
7、很早以前就实现了。NetBeans 平台在类库的管理方面已经走的相当远：它积极的参与类库的加载过程，并强制每一个类库都满足其他类库对自己的最低版本需求。这样的类库被称为模块。NetBeans 模块系统是一个运行时容器，它确保了系统在运行时的完整性。 版本控制版本控制 将应用程序分解为独立的类库，这带来了一个新的挑战我们需要确保这些互不依 赖的零件们能够在一起工作。这个问题有多种解决方案，而最流行的一种就是版本控制。 每一块模块化应用都有一个版本号，常用杜威十进制格式表示，比如 1.34.8 这种数字组合。 新版本的发布带来增加的版本号，比如 1.34.10，1.35.1，或者 2.0。其实仔细
8、想来，使用增 长的版本号来代表两个版本的复杂软件之间的不同是挺荒谬的。不过这种方法解释起来很 简单，而且它的流行也说明了这种方法是十分可行的。 一个模块系统的另一个特点是外部依赖的声明。很多组件对外部条件有一定需求。比 如说，一个模块系统中的组件可能需要一个 XML 解析器，或者需要安装某种数据库驱动，或者需要某种文本编辑器或者浏览器才能工作。对于每一个需求，另外一个模块可以指定 其接口的特定版本号。即使对外部类库的依赖性极低，但每一个 Java 程序都对 Java 本身 有版本要求。一个真正的模块系统可以指定理想的最低 JDK 版本。一个模块可能会有 JDK=1.5，xmlparser=3.
9、0，webbrowser=1.5 这样的版本需求。在运行时，启动应用的模 块代码的依赖条件需要被满足，即，XML 解析器在 3.0 版或以上，浏览器在 1.5 版或以上， 如此这般。NetBeans 模块系统正是这样的。使用依赖模式来维持模块系统中组件之间的依 赖性有一个大前提，那就是我们必须遵循一系列的规则。第一个规则是向后兼容性：如果 新版本发布，那么所有在之前版本下可建立的契约也必须能够在新版本下工作。这一点说 起来很容易，但实现起来没那么容易。第二个规则是，系统中的组件需要准确的说明它们 需要什么。当一个模块的依赖性产生改变的时候，它必须要说出来，这样系统才能够准确 的确认这些依赖性是
10、否被满足。因此，如果一个模块系统产生了对新功能的依赖性，比如 一个 HTML 编辑器，那么你便需要定义这个新的依赖性（比如，htmleditor=1.0） 。同时如 果你开始使用一个新的 HTML 编辑器组件的接口，而这个接口在 1.7 版之后才有，那么你 需要更新你的依赖型需求到这个组件的 1.7 版本：htmleditor=1.7。在 NetBeans 模块系统 中，第二个规则在实践当中是相对容易遵循的，因为一个模块的编译时类路径仅仅包括有 依赖性声明的模块，而没有依赖性声明的模块是不会被编译的。 二级版本信息二级版本信息 之前我们有关版本控制方法的讨论针对的是类库的规范版本。规范版本描述
11、了该类库 当中的公共 API 的一个特定快照。 某些版本的类库会不可避免的遭遇不得不修复的 bug。因此，二级版本的识别也应该 与组件关联起来，那就是这个组件的实现版本。与规范版本不同，一个实现版本往往用 “Build20050611”这样的字符串进行标注，因此只能通过等式来判定。这就提供了一个二级 识别机制，这个机制可以用来决定某个特定的代码模块是否有必须修复的 bug。我们知道， 在 3.1 规范版本中存在的 bug 未必会在 3.2 版本或者 3.1 版本的其他实现版本中存在，因此， 出于 bug 修复或某些特殊处理的需求，将实现版本与类库关联起来是十分有用的。 依赖性管理依赖性管理 版
12、本和依赖性系统需要一个管理器，以确保这个系统中的每一部分的需求都得到满足。 这样的一个管理器可以检查每一块组件的安装时间，保持系统的一致性Linux 发行版 的 RPM 或 Debian 包就是这样工作的。描述依赖性的元数据在运行时非常重要。有些元数 据可以让应用进行动态类库升级而无需关闭应用。元数据还能决定一个模块动态加载的依 赖性是否满足。如果没有满足，元数据将向用户解释可能会遇到的问题。 NetBeans IDE 是一个模块化应用。它的模块即组成它的那些类库在运行时被 查知并加载。它们可以安装小块小块的功能，如组件，菜单项或服务等；它们可以在启动 时运行代码，进行程序初始化；它们可以通过声明式注册机制把平台和 IDE 提供的各个部 分注册为服务并在需要时将其初始化。NetBeans 模块系统使用安装组件的声明依赖性为每 个模块的类路径进行父类路径配置，并在模块加载类的时候决定在哪些 JAR 文件当中搜索。 这样确保了模块类路径当中不存在任何不属于其依赖树的模块 JAR，并强制确保每个组件 都有声明式依赖性。一个没有声明依赖性的模块将无法从其他模块中呼叫代码，而当依赖性没有被全部满足时，其他模块将不会加载。
