fedora 使用java编程-fedora 20 使用

JAVA技能：模块化编程的优势与实现原理概述 2010-01-27 09:30 中文技术社区推荐的NetBeans学习书籍）英文版公章，即第二章的节选翻译，章节的标题是“模块化编程的好处”。 通过阅读本章，读者将初步了解模块化编程的由来和实现原理，了解模块化编程的优点。 对于模块化编程的实现部分，本文重点介绍NetBeans的情况。 闭门造车进行分布式开发的软件开发时代早已过去。 在嵌入式系统之外，几乎每个开发人员都需要依赖其他人编写的类库或框架。 使用和重用他人提供的基础设施、框架和类库的好处是，你可以专注于应用程序本身的逻辑。 这缩短了软件开发所需的时间。 过去几十年开源软件的兴起使类库的重用具有双重吸引力。 我们现在各种程序中的各种问题都有现成的解决方案，而且不需要一分钱就能搞定。 开源产品从 UNIX 内核、基本的 C 类库​​和命令行工具开始，通过 Web 服务器和 Web 浏览器扩展到 Ant、Tomcat、JUnit、Javacc 等 Java 工具——而且这种情况有无限的发展趋势。

在编写一个现代软件的过程中，集成工作和创新工作大致分为两半。 挑选和组合可用的部分是现代应用程序开发的主要部分。 人们不再从头开始编写所有代码。 人们在需要 HTTP 服务器时选择 Apache 或 Tomcat 作为他们的应用程序，而在他们需要数据库时选择 MySQL 或 PostgreSQL。 应用软件将这些点点滴滴粘合在一起，并添加了自己的逻辑。 最终产品是在相对较短的时间内开发出的功能齐全、性能良好的应用软件。 查看 Linux 发行版是如何分发的。 Red Hat 的 Fedora、Mandriva、SUSE 和 Debian 都包含由同一个人编写的大致相同的应用程序。 出版商只需将它们打包并提供统一安装的“胶水”。 出版商往往只编写中央管理软件和安装软件，并提供一些质量保证以确保所有选定的组件协同工作。 这个过程对 Linux 的普及产生了相当理想的影响。 这个模型的一个例子是 Mac OS X：它实际上只是安装了一堆 Apple 插件的 FreeBSD Unix。 关于此类软件需要注意的重要一点是它是使用分布式开发模型创建的。 软件的开发者和发布者可能根本不认识，也没有往来，而且往往不住在同一个地区。

这种分布式开发具有以下特点。 首先，应用程序（或操作系统）的源代码不再完全由单个开发人员控制。 源代码分布在世界各地。 毫无疑问，构建此类软件与源代码完全在您的家庭代码库中的传统应用程序构建有很大不同。 我们需要了解的另一件事是，没有人可以完全控制整个项目进度。 不仅仅是源代码，开发人员遍布世界各地并按照自己的时间表工作。 这种情况并不像听起来那么不寻常或不可靠。 如果您曾经为一个超过 50 人的项目制定过时间表fedora 使用java编程，您就会知道“完全控制”整个项目过程充其量只是一种令人欣慰的幻想。 任何时候你都需要准备好放弃一个特性，或者发布这个或那个组件的旧版本。 同样的模式也适用于分布式开发。 每个人都有这样的权利：使用新版本或旧版本类库的自由。 使用外部库并使用它们来编写应用程序意味着人们可以用更少的时间和精力创建更复杂的软件。 代价是我们需要管理这些库以确保它们的兼容性。 这不是一件容易的事。 然而，对于当今高度复杂的系统的形成，没有其他的开发模式既实用又经济。 模块化应用程序 应对分布式开发挑战的技术解决方案是模块化。 在一大段紧密耦合的代码中，每个单元都可以直接与其他单元交互。

另一方面，模块化应用程序由小的、离散的代码块组成，每个代码块都是独立的。 因此，这些代码块可以由不同的团队开发，它们都有自己的生命周期和时间表。 最终产品可以由另一个独立实体，即发行人整合。 对于Java来说，把一套类库放到Java类路径上，运行一个应用程序早就实现了。 NetBeans 平台在库管理方面已经走了很长一段路：它积极参与库加载过程，并强制每个库满足其他库的最低版本要求。 这样的类库称为模块。 NetBeans 模块系统是一个运行时容器，可确保系统在运行时的完整性。 版本控制将应用程序分解为独立的类库，这带来了新的挑战——我们需要确保这些独立的部分能够协同工作。 这个问题有多种解决方案，其中最流行的一种是版本控制。 每个模块化应用程序都有一个版本号，通常用杜威十进制格式表示，例如1.34.8等数字的组合。 新版本带来增量版本号，例如 1.34.10、1.35.1 或 2.0。 实际上，仔细想想fedora 使用java编程，使用递增的版本号来表示复杂软件的两个版本之间的差异是荒谬的。 不过这个方法解释起来很简单，它的流行也说明这个方法是非常可行的。

模块系统的另一个特点是外部依赖的声明。 许多组件对外部条件有一定的要求。 例如，模块系统中的组件可能需要 XML 解析器、某种数据库驱动程序或某种文本编辑器或浏览器才能工作。 对于每个需求，另一个模块可以指定其接口的特定版本号。 即使对外部类库的依赖最小，每个 Java 程序对 Java 本身都有版本要求。 真正的模块系统可以指定理想的最低 JDK 版本。 一个模块可能有JDK>=1.5、xmlparser>=3.0、webbrowser>=1.5等版本要求。 在运行时，需要满足启动应用程序的模块代码的依赖关系，即3.0或以上版本的XML解析器，1.5或以上版本的浏览器等。 NetBeans 模块系统就是这样做的。 使用依赖模型来维护模块系统中组件之间的依赖关系有一个很大的前提，那就是我们必须遵循一系列的规则。 第一条规则是向后兼容性：如果发布了新版本，所有可在先前版本下构建的合约也必须在新版本下工作。 这说起来容易，但实现起来就没那么容易了。 第二条规则是系​​统中的组件需要准确指定它们需要什么。 当一个模块的依赖关系发生变化时，必须报告，以便系统准确地确认这些依赖关系是否得到满足。

因此，如果模块系统创建了对新功能的依赖，例如 HTML 编辑器，那么您需要定义这个新的依赖（例如，htmleditor>=1.0）。 同时，如果你开始使用一个新的HTML编辑器组件的接口，而这个接口是1.7版本以后才有的，那么你需要更新你的依赖需求到这个组件的1.7版本：htmleditor>=1.7。 在 NetBeans 模块系统中，第二条规则在实践中比较容易遵循，因为模块的编译时类路径只包含有依赖声明的模块，没有依赖声明的模块不会被编译。 二级版本信息 我们之前对版本控制方法的讨论是针对类库的规范版本的。 规范版本描述库中公共 API 的特定快照。 某些版本的库将不可避免地遇到必须修复的错误。 因此，二次版本的标识也应该与组件相关联，即该组件的实现版本。 与规范版本不同，实现版本通常标有“Build20050611”这样的字符串，因此只能通过等式来确定。 这提供了一种辅助识别机制，可用于确定特定代码模块是否具有必须修复的错误。 我们知道，3.1规范版本存在的bug，在3.2版本或者3.1版本的其他实现版本中不一定存在。 因此，对于bug修复或者一些特殊的处理需求，将实现版本与类库相关联是非常重要的。 有用。

依赖管理 版本控制和依赖系统需要一个管理器来确保满足系统每个部分的要求。 这样的管理器可以检查每个组件的安装时间，使系统保持一致——这就是 Linux 发行版 RPM 或 Debian 软件包的工作方式。 描述依赖关系的元数据在运行时非常重要。 一些元数据允许应用程序在不关闭应用程序的情况下执行动态类库更新。 元数据还可以确定是否满足模块动态加载的依赖项。 如果不满足，元数据将向用户解释可能遇到的问题。 NetBeans IDE 是一个模块化应用程序。 它的模块——即构成它的类库——在运行时被检测和加载。 他们可以安装小块功能，例如组件、菜单项或服务； 他们可以在启动时运行代码并执行程序初始化； 他们可以通过声明式注册机制将平台和 IDE 的各个部分注册为服务，并在需要时对其进行初始化。 NetBeans 模块系统使用已安装组件声明的依赖关系到每个模块类路径的父类路径配置，并确定在模块加载类时搜索哪些 JAR 文件。 这确保模块的类路径上没有不属于其依赖关系树的模块 JAR，并为每个组件强制执行声明依赖关系。 没有声明依赖的模块将无法调用其他模块的代码，当依赖不全部满足时，其他模块将不会被加载。