围城书评_书评：Java应用程序体系结构

围城书评

Java应用程序体系结构：使用OSGi的带有示例的模块化模式是Kirk Knoerschild的开创性著作，内容涉及如何通过提供十八种模式的目录来设计应用程序设计中的模块化。

本书的第一部分通过讨论模块的运行时和开发支持来论证模块化的理由。 然后，在此基础上，展示了如何在设计时使用模块化来促进体系结构，以及如何将其与面向服务的体系结构集成。 最后，有一个参考实现，显示了各部分如何装配在一起。

本书的第二部分是模式目录，分为五个不同的部分，在网站的模式目录中列出 ：

• 基本模式
  • 管理关系 –设计模块关系
  • 模块重用 –强调模块级别的可重用性
  • 内聚模块 –模块行为应达到单一目的
• 依赖模式
  • 非循环关系 –模块关系必须是非循环的。
  • 均衡模块 –模块关系应该均衡 。
  • 物理层 –模块关系不应违反概念层。
  • 容器独立性 –模块应独立于运行时容器。
  • 独立部署 –模块应为可独立部署的单元。
• 可用性模式
  • 发布接口 –使模块的发布接口众所周知。
  • 外部配置 –模块应可在外部配置。
  • 默认实现 –为模块提供默认实现。
  • 模块外观 –创建外观作为另一个细粒度模块的基础实现的粗粒度入口点。
• 可扩展性模式
  • 抽象模块 –取决于模块的抽象元素。
  • 实现工厂 –使用工厂创建模块的实现类。
  • 单独的抽象 –将抽象和实现它们的类放在单独的模块中。
• 效用模式
  • 并置异常 –异常应该与引发它们的类接近。
  • 分层构建 –根据模块分层执行构建。
  • 测试模块 –每个模块都应具有一个相应的测试模块，以验证其行为并说明其用法。

本书的最后一部分介绍了OSGi的模式应用程序，作为Java模块系统的示例。 尽管本部分是OSGi专用的，但本书其余部分的模式适用于Java中的任何模块系统，包括即将推出的Jigsaw项目，并为那些希望在没有运行时模块系统的情况下构建模块化软件的人提供指南。

InfoQ赶上了Kirk，并询问了他对软件和模块化的想法，然后从询问过去几十年来软件复杂度如何变化开始：

柯克 ：毫无疑问，软件在过去几十年中得到了发展。 功能更强大的硬件以及表达能力更强的编程语言使创建功能更强大的软件系统变得更加容易。

如今，大多数开发人员不必再为处理严重的内存限制和有限的处理能力而担心。 例如，于韦斯屈莱大学进行的一项研究表明，1990年有1200亿行代码，到2000年，行数增加了一倍以上，达到2500亿行。 该研究还声称，代码行的数量每七年翻一番。

这是惊人的，而且是透视图，这意味着在接下来的七年中，我们将编写的代码比自从有人编写第一行代码以来编写的代码还要多。 在许多方面，代码的增长并不是一件坏事。 如果软件没有发展壮大，它最终将消亡。 使用软件的人自然对软件有更多要求，因此我们推出了新版本并进行升级以支持我们的用户。 但是更多的代码意味着更多的维护。 维护大型系统本质上比小型系统更加困难。

信息 问：软件的设计和架构产生了什么影响？

柯克 ：不幸的是，它尚未产生重大影响。 在许多方面，我们今天仍然像15或20年前一样设计软件。 但这是不可持续的，需要改变。

开发单片软件不再合适。 SOA和服务是朝正确方向迈出的一步，但这仅解决了部分挑战。 服务设计最困惑的方面之一是确定服务粒度。 太粗粒度了，该服务在各种不同的上下文中不能做太多有用的事情（即可重用），而又太细粒度了，并且该服务做不到有用的事情（即可用性）。

正如我在书中讨论的那样，最大化重用会使使用变得复杂。 单层抽象无法解决此问题。 附加级别是必要的，而模块化是下一个级别。 模块化是下一步，它将帮助您“从头到尾”进行架构设计。

结果是您可以使用现有模块以正确的粒度级别组合服务。 与服务的粒度级别不同的模块可帮助您从头到尾构建。

InfoQ：JVM上模块化的未来是什么？

柯克 ：JVM上的模块化有很多事情要做。 OSGi已融入几乎所有主要供应商的产品中，并且可以在当今的许多组织中使用。

不幸的是，OSGi尚未在企业中引起关注。 有人认为它太复杂了，但是他们真正要说的是设计模块化软件很困难。 对于那些熟悉Frederick Brooks的人来说，问题集中在软件开发的基本复杂性上。 建筑和设计非常困难。

然而，具有弹性，可延展性，灵活性和可维护性的软件对于成功至关重要，尤其是在当今快节奏的企业环境中，那里对软件开发团队的交付需求比以往任何时候都要大。 当然，OSGi不是唯一的模块系统。 Oracle还将Jigsaw集成到Java SE中，该产品将于2013年某个时候上市。模块化已经进入Java平台，它将改变我们设计软件系统的方式。

在 FOQ：是什么让你决定编写Java应用程序体系结构？

柯克 ：大约10年前，我意识到我所设计的软件存在严重问题。 我们将所有这些精力投入到设计非常好的类结构中，然后将所有内容打包到这个庞大的单个可部署单元中，例如EAR或WAR文件。 感觉不对。 所有这些努力都花在了创建灵活的软件上，但是在重用性，可维护性或灵活性方面，我们并没有看到明显的好处。

大约在同一时间，我签署了第二本书，并计划撰写有关软件模式的文章。 我在设计中遇到的困惑问题一直延续到我的写作中。 缺少的东西使我无法实现所寻求的优势。 我一直是Bob Martin的SOLID原理以及GOF模式的忠实拥护者 。 我还开始研究Clemens Szyperski（他是“ 组件软件：超越面向对象的编程 ”的作者）和John Lakos（他写了“ 大规模C ++软件设计 ”）的著作。 我将所有这些概念结合在一起，并开始通过将JAR文件作为模块化单位来改变设计软件系统的方式。

在接下来的几年中，我磨练了这种方法。 通过使用JAR文件作为模块化单位，我突然能够实现我寻求的许多优势。 您在书中看到的模式是大约10年前开始的结果。 同时，我有一本书的完成率大约为70％，但其中没有包括我同期所采用的许多概念。 因此，我花了一些时间离开本书，继续证明这些模式，大约两三年前，他与一位很有耐心的出版商联系，让他们知道我已经准备好了。 幸运的是，他们给了我另一个机会，其结果就是模块化模式。 也许这更多地解释了这本书的来历，而不是我写这本书的原因。

最终，我之所以写它，是因为这些模式在改进我开发的系统方面起着很大的作用，并且我想与世界分享。

InfoQ：这本书是OSGi特定的吗？

柯克 ：绝对不是。 它不特定于任何模块框架。 这些模式以及实际上是整本书都旨在与当今标准Java中可用的所有内容一起使用。 实际上，直到大约2006年，即我开始这一旅程大约四年后，我才发现OSGi。

我对OSGi的发现实际上有些顿悟。 我发现了一个由志同道合的人组成的社区，以及一个为许多模式提供运行时支持的框架。 随着我对OSGi的了解越来越多，我开始就将现有应用程序迁移到OSGi所需的想法提出建议。

该书提供了一些示例来演示OSGi，但主要目的是演示OSGi的优势，并使人们了解将系统从标准Ja​​va迁移到OSGi所需要的内容。

信息 问：即使您不使用OSGi或Jigsaw，也可以应用模块化吗？

柯克 ：当然。 在第2章中，我将讨论模块化的两个方面–运行时模型和开发模型。 开发模型可以细分为编程模型和设计范例。

模块框架将为您提供编程模型和运行时模型。 但是没有框架可以帮助您设计一套好的模块。 这留给开发人员，这是本书的重点。

我喜欢与面向对象的范例进行类比。 仅仅因为一种语言支持继承，多态性，封装和动态绑定，并不意味着可以保证优秀的面向对象软件。 设计模式可以帮助您。

模块化也是如此。 即使您使用的是模块框架，也不能保证模块化软件。 因此，本书的目的是首先帮助您设计模块化软件，无论您使用的是OSGi，Jigsaw还是仅使用标准Java。 这样，您可以立即开始采用本书中的概念，而无需采用任何新框架或进行任何其他基础架构投资。

大多数代码示例使用标准Java来演示这些概念。 我添加了使用OSGi构建的其他几个代码示例，以说明您从运行时支持模块化中获得的其他好处。 因此，除了可以帮助您当今设计模块化软件之外，本书中的概念还为您提供了在模块化可用时以及准备开始使用模块化时的运行时支持。

信息 问：模块化是否仅与重用有关？

柯克 ：重用很有趣，因为重用很有价值。 我的意思是，过去二十年来的主要技术趋势都以重复使用为主要优势。 在90年代，它是面向对象的编程。 此后不久，它就是基于组件的开发。 然后，我们进入了面向服务的体系结构。

具有讽刺意味的是，他们每个人都没有辜负期望，许多开发团队继续在重用方面挣扎。 当然，重用是模块化的优势，但不是万能药。 模块化填补了其他方法无法做到的空白，因为模块化使您可以专注于不同层次的抽象和粒度上的设计。 如果您阅读本书的第2章和第5章，将会看到差距存在的地方，以及模块化的帮助方式。

但是模块化也有其他几个优点。 其中包括更好的可维护性，依赖性管理，以及简单地提高您了解非常复杂的软件系统的能力。 本书第1部分中的几章详细讨论了这些想法。

问题 ：模块化是否可以应用于现有系统，还是需要预先设计？ 是否可以将系统重构为更具模块化？

柯克（Kirk） ：如果您同时开始考虑架构和设计，那么就更容易考虑模块化了。 但是，如果您拥有现有系统，则仍然可以对其进行模块化，特别是如果您具有良好的类设计。 实际上，这本书的第8章通过使用一个不是非常模块化的现有系统，并使用这些模式应用了几种重构，来引导您完成本练习。 结果是高度模块化的系统。 这是一个非常有力的例子，展示了模块化的好处。

执行此练习时通常会发生一些非常有趣的事情。 您开始发现班级设计中不存在的缺陷。 例如，几乎每个团队都试图对其软件系统进行分层。 通常，这意味着它们将具有表示层，域和数据访问层。 但是这些是逻辑层。 也就是说，它们在概念上存在于类结构中，但在物理上不存在于可部署单元之间。

当您尝试将软件分层到模块中时，您开始关注可部署单元。 在执行此操作时，通常会发现对您不了解的逻辑层有一些违反。 我将在“物理层”模式中进一步讨论这一点。

信息 问：您认为Java模块化的未来是什么？

Kirk ：模块化将改变我们在Java平台上开发和交付软件系统的方式。 从开发的角度来看，它填补了其他主要设计范例所留下的空白。 对于交付软件，它标志着整体和静态平台的终结。 这将使更强大的生态系统出现，使开发人员能够轻松地从存储库中配置模块。

也许，鉴于移动生态系统中围绕应用程序店面的兴奋程度，该存储库将类似于“企业模块存储库”之类的东西。 其中一些模块可能是免费的，而其他模块则需要付费。 它使您可以从几个不同的来源整理运行时环境。 在某个时候，环境可能会根据您的应用程序的基础结构要求自行组装。

可以在该书的网站 （以及移动优化版 ）上找到该书的样式的完整列表。 本书提供了一个示例 ，而GitHub上提供了模式示例的代码。 该书可从亚马逊以印刷形式以及Kindle和iBooks电子格式购买。

此问答基于Kirk Knoernschild撰写的“ Java应用程序体系结构：使用OSGi的模块化模式与示例”一书，该书由Pearson / Prentice Hall Professional于2012年3月出版，ISBN0321247132。有关更多信息，请访问此网站 。

翻译自: https://www.infoq.com/articles/java-application-architecture/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

围城书评