rao*_*son 27 java complexity-theory osgi modularity
我看到很多关于OSGi的演讲,我认为这对于实施更好的模块化听起来很有希望.显然,"热部署"和"并行运行不同版本的x"也是市长的卖点.
我想知道OSGi承诺解决的问题是否是一个问题......？它让我想起OO的早期时代,类似的声称是女仆:
当OO是新的时,最重要的论点是可重用性.人们普遍声称,当使用面向对象时,人们只需要"一次写入",然后就可以"随处使用".
在实践中,我只看到这个适用于一些非常低级的例子.我认为这样做的原因是编写可重用的代码很难.从技术上讲,但从界面设计的角度来看.您必须预测未来的客户将如何使用您的课程并提前做出正确的选择.根据定义,这很困难,因此潜在的可重用性益处通常无法实现.
有了OSGi,我怀疑在这里我们可能会再次陷入承诺,我们没有真正拥有的问题的潜在解决方案.或者如果我们拥有它们,我们没有足够大的数量和严重程度,以便购买OSGi以获得帮助."Hotdeployment",例如模块的子集的绝对是一个好主意,但多久它真正的工作？多久没有,因为事实证明你对特定问题的模块化是错误的？如何在多个模块之间共享模型实体？这些模块都必须同时更换吗？或者,您是否将对象展平为基元并仅使用模块间通信中的对象,以便能够保持接口契约？
应用OSGi时最困难的问题是,我认为,使模块化"正确".类似于在OO中使用OSGi获取类的接口,问题保持不变,这次是更大规模,包甚至服务级别.
正如您可能已经猜到的那样,我目前正在尝试评估OSGi以用于项目.我们遇到的主要问题是随着代码库的增长而增加复杂性,并且我希望在具有越来越多定义的交互的较小模块中打破系统.
谢谢!
Mar*_*ans 21
OSGi得到了回报,因为它在运行时强制执行模块化,这是您以前没有的,通常会导致纸上设计和实现分离.这可能是开发过程中的一大胜利.
如果您让团队专注于单个模块(可能是一组捆绑),并且您的模块化正确,那么它肯定有助于让团队更轻松地工作.有人可能会说,使用像Ant + Ivy或Maven和依赖项这样的构建工具可以做同样的事情,OSGi使用的依赖关系的粒度在我看来远远优于,不会导致典型的"拖入一切加上厨房水槽" JAR级别依赖性导致.
具有较少依赖性的模块化代码往往会导致更清晰,更少的代码,从而导致更少的错误,更容易测试和解决.它还促进设计组件尽可能简单和直接,同时可以选择插入更复杂的实现,或者将缓存等方面添加为单独的组件.
即使您不在运行时使用热部署,也是一个非常好的测试,可以验证您是否正确地模块化了应用程序.如果您无法以随机顺序启动捆绑包,则应调查原因.此外,如果您可以更新任意捆绑包,它可以使您的开发周期更快.
只要您可以管理您的模块和依赖项,大项目就可以管理并且可以轻松演化(从可以说是糟糕的"完全重写"中拯救您).
OSGi的缺点？这是一个非常低级的框架,虽然它可以很好地解决问题,但仍有一些事情你需要自己解决.特别是如果您来自Java EE环境,在那里您可以获得免费的线程安全性以及其他一些在您需要时非常有用的概念,您需要自己在OSGi中为这些提供解决方案.
一个常见的缺陷是不在OSGi之上使用抽象来使普通开发人员更容易.永远不要让他们手动弄乱ServiceListeners或ServiceTrackers.仔细考虑捆绑包是什么,不允许这样做:您是否愿意让开发人员访问BundleContext,或者使用某种形式的声明性模型来隐藏所有这些内容.
我已经使用OSGi多年了(虽然在eclipse项目的上下文中,而不是在web项目中).很明显,框架并没有让你思考如何模块化.但它使您能够定义规则.
如果您使用包并定义(在设计文档中？Verbal？)某些包可能无法访问其他包中的类,而没有强制执行此约束,它将被破坏.如果您雇用新的开发人员,他们不了解规则.他们会破坏规则.使用OSGi,您可以在代码中定义规则.对我们来说,这是一个巨大的胜利,因为它帮助我们维护了我们系统的架构.
OSGi不会降低复杂性.但它肯定有助于处理它.
我现在使用OSGI超过8年了,每次我在非OSGI项目中潜水,我都会感觉没有系安全带而超速超速.OSGI使项目设置和部署更加困难,并迫使您提前考虑模块化,但是您可以轻松地在运行时强制执行规则.以maven apache camel为例.当您创建一个新的maven项目并添加apache camel作为依赖项时,应用程序似乎具有所有依赖项,并且您只会在运行时注意到ClassNotFoundExceptions,这很糟糕.当您在OSGI容器中运行并加载apache camel模块时,未启动具有未满足依赖关系的模块,并且您事先知道问题所在.
我还一直使用热部署,并且无需重新启动即可快速更新应用程序的部分内容.
| 归档时间： |
|
| 查看次数： |
1691 次 |
| 最近记录： |