OSGi 能否帮助降低复杂性？

java complexity-theory osgi modularity

2022-09-01 15:43:29

我在OSGi上看到了很多演讲，我认为它听起来很有希望强制实施更好的模块化。显然，“热部署”和“并行运行不同版本的x”也是市长的卖点。

我想知道OSGi承诺解决的问题是否是一个问题......？这让我想起了OO的早期，当时类似的索赔是女仆：

当OO是新的时，最大的争论是可重用性。人们普遍认为，当使用OO时，人们只需要“写一次”，然后就可以“到处使用”。

在实践中，我只看到这适用于一些非常低级的例子。我认为这样做的原因是编写可重用的代码很难。不是技术上，而是从界面设计的角度来看。你必须预测未来的客户将如何使用你的课程，并提前做出正确的选择。根据定义，这很困难，因此潜在的可重用性优势往往无法实现。

有了OSGi，我怀疑在这里我们可能会再次陷入承诺，潜在的解决方案，以解决我们真正没有的问题。或者，如果我们有它们，我们就没有足够大的数量和严重性来证明购买OSGi寻求帮助是合理的。例如，模块子集的“热部署”绝对是一个好主意，但它真正起作用的频率如何？有多少次不是因为事实证明你对特定问题的模块化是错误的？在多个模块之间共享的模型实体怎么样？这些模块是否都必须同时更改？或者，您是否将对象扁平化为基元，并仅在模块间通信中使用那些对象，以便能够保持接口协定？

我认为，应用OSGi时最困难的问题是“正确”地实现模块化。与在OO中获取正确的类接口类似，使用OSGi，问题保持不变，这次是更大的规模，包甚至服务级别。

正如您可能已经猜到的那样，我目前正在尝试评估OSGi以用于项目。我们遇到的主要问题是，随着代码库的增长，复杂性越来越高，我想将系统分解成更小的模块，这些模块具有越来越少的交互。

鉴于没有任何框架可以帮助决定模块化的内容，OSGi是否为您带来了回报？
在团队中工作时，它是否使您的生活更轻松？
它是否有助于减少错误计数？
您是否曾经成功“热部署”主要组件？
随着时间的推移，OSGi是否有助于降低复杂性？
OSGi是否信守承诺？
它满足了您的期望吗？

谢谢！

答案 1

OSGi之所以有回报，是因为它在运行时强制实施模块化，这是你以前没有的，通常会导致纸上的设计和实现渐行渐远。在开发过程中，这可能是一个巨大的胜利。

如果你让团队专注于单个模块（可能是一组捆绑包），并且如果你正确地实现了模块化，这绝对有助于使团队中的工作更容易。有人可能会争辩说，可以使用像Ant +Ivy或Maven这样的构建工具以及依赖项来做同样的事情，在我看来，OSGi使用的依赖项的粒度要优越得多，而不会导致JAR级依赖项导致的典型“拖入所有内容加上厨房水槽”。

具有较少依赖性的模块化代码往往会导致更清晰，更少的代码，从而导致更少的错误，更易于测试和解决。它还促进了尽可能简单明了地设计组件，同时可以选择插入更复杂的实现，或者将缓存等方面添加为单独的组件。

热部署，即使您不在运行时使用它，也是一个非常好的测试，可以验证是否正确模块化了应用程序。如果您根本无法以随机顺序启动捆绑包，则应调查原因。此外，如果您可以更新任意捆绑包，它可以使您的开发周期更快。

只要你能管理你的模块和依赖关系，大项目就保持可管理性，并且可以很容易地发展（将你从可以说是糟糕的“完全重写”中拯救出来）。

OSGi的缺点是什么？这是一个非常低级的框架，虽然它很好地解决了它所针对的问题，但还有一些事情你仍然需要自己解决。特别是如果你来自Java EE环境，在那里你可以获得自由线程安全和其他一些概念，如果你需要它们，它们可能非常有用，你需要自己在OSGi中为这些概念提出解决方案。

一个常见的陷阱是不要在OSGi之上使用抽象，以使普通开发人员更容易做到这一点。永远不要让他们手动弄乱ServiceListeners或ServiceTrackers。仔细考虑哪些捆绑包是允许的，哪些是不允许的：您是愿意让开发人员访问 BundleContext，还是通过使用某种形式的声明性模型来隐藏所有这些内容。

答案 2

我已经使用OSGi好几年了（尽管在eclipse项目的上下文中，而不是在Web项目中）。很明显，该框架并不能让您摆脱如何模块化的思考。但它使您能够定义规则。

如果使用包并定义（在设计文档中？口头？某些包可能无法访问其他包中的类，如果不强制执行此约束，它将被破坏。如果您雇用新开发人员，他们不知道规则。他们会打破规则。使用OSGi，您可以在代码中定义规则。对我们来说，这是一个巨大的胜利，因为它帮助我们维护了系统的架构。

OSGi 不会降低复杂性。但它绝对有助于处理它。