OSGi（Open Service Gateway Initiative）是关于通过在框架中安装一套（可重用的）模块，如何创建一个有用的应用。基本上，我们在1998年开始着手解决组件编程模型；令人惊奇的是，我觉得我们主要的成功来源于很多成功的OSGi项目。那么，任务已经完成了吗？

　　不见得，看看企业世界中关于OSGi的探讨：Spring、Jigsaw等等。很多人喜欢它，一些人似乎极度讨厌它（伙计们，别烦了，它就是个技术而已）。我的解释是OSGi违反了一些企业开发者的基本期望值，OSGi应该就是类路径上的一个库，提供一些有用的且便捷的功能，但是在别的方面要置身事外。

　　模块化是关于你的代码基的；OSGi仅仅是一个微小层，为性能良好的模块提供运行时环境。OSGi并不是什么会让应用瞬间模块化的“神秘酱汁”。就像面向对象强制结构化程序员差异思考，模块化迫使现在的开发者摆脱框框（和代码基），开始收获好处。模块化是架构！

　　正如我们长久以来在OSGi内部进行模块化，我们发现很多现有的软件模式本质上是非模块的，而且已经开发了模块替代物。此外，我们发现这些模块化解决方案仅仅被开发者所理解，这些开发者是实际工作在模块化环境中的。对于其他人来说，它就像是官方文件。

　　就像所有的next-next问题一样（在你解决下一个问题的时候就会遇到这个问题），模块化OSGi解决方案常常会让人觉得过于复杂且不必要，如果一个人还没有体会道next-next问题的痛苦，这样像也合乎逻辑。本文中我为目前的一些最佳实践来尝试解释稳健的模块化所带来的意想不到的结果。

　　Java中的模块化是关于（简言之）将你的JAR转到一个模块中。模块依赖于其他模块，而且它们可以隐藏实施细节。模块之间的领域就仅仅是精确的共享包。正如实施细节是保密的，我们可以在未来的版本中改变它们，这也正是模块化的主要好处。在我们的编程模型中，这种隐藏会有什么影响呢？

　　行业中一个完全的最佳实践就是接口基于编程。取代使用实施类，我们使用接口。接口消费者不会同任何提供者的实施细节耦合。这种解耦为我们提供了重用和替换；测试变得更容易等等。我还没有遇到哪个企业开发者不理解这些好处的。下图展示的就是这种类型的耦合模型：

耦合模型

　　接口允许我们描绘出我们系统中耦合的一种乐观观点，在UML中，消费者和提供者之间没有耦合、不幸的是，这个UML并不是真实世界的实际反映；在系统的某个深处，不可避免的潜藏着耦合的实施类。业内已经同这个问题斗争了很长时间，通过大量著名的模式来解决这个问题。坏消息就是几乎所有的模式都破坏了模块性。

　　例如，我们有一个消费者（C）和一个提供者（P）模块，提供者提供FooImpl类用以实施接口Foo。传统方式下，消费者仅仅是“new FooImpl()”来为Foo接口创建一个实现：

FooImpl类

　　如红箭头所指出的，随着消费者请求访问提供者的一个实施细节类FooImpl，这个就触犯了模块的边界。即使没有模块，这个对于使用也是不舒服的，而且导致在四人帮（Gang of Four）的设计模式书中大多数成功的模式：Factory pattern（工厂模式）。取代消费者抓取一个实施类，称之为FooFactory.create()方法，然后知道如何创建一个期望的实施。

工厂模式

　　这个迂回对于我们的消费者来说是好消息，因为真正从提供者这里解耦了。然而，正如图片所示，Factory仍旧不得不违背提供者的模块边界，也就是FooImpl类。是的，它可以被隐藏在文本/XML源中，但是这并不意味着耦合就不存在了。这也是一种有点尴尬的模式，因为它也具有所有全局和单独的问题。

　　在《OSGi是所有模块化应用的框架（下）》中，我们将继续为您介绍相关内容。