基于组件的体系结构的粒度

Question

虽然我是一名Java开发人员,但这个问题涉及OSGi和基于Java的模块化,这个问题确实适用于任何面向对象的3GL.

我开始掌握真正"模块化"开发的概念,并开始真正喜欢OSGi.我有史以来第一次开始考虑在非常精细,可重用的专用部署中部署jar.然而,这种新的思维模式引发了一些问题.

在基于组件的纯体系结构中,每个类都会受到震动吗？如果不是组件的粒度应该是多少？是否有可能使每个组件都可重复使用？

在确定模块化组件的粒度时,使用哪些"经验法则"？提前致谢!

Answer 1

我将主要从OSGi的角度来回答这个问题.

恕我直言,区分组件和模块很重要.一个组件是一种编程假象:一些有行为,并可以提供给其他组件的服务.在实现方面,您使用OSGi的组件模型之一(例如Declarative Services)对组件进行编程.请参阅http://wiki.osgi.org/wiki/Component_Models_Overview

甲模块是一个部署假象:它是部件和/或API的包装成能够围绕被复制和安装在各种运行时间伪影.因此,隐式地,您可以在一个模块中打包多个组件,或者为每个组件创建一个模块.

事实上,模块内容很容易重构,因此您不必过于担心粒度:随着您获得OSGi的更多经验,您将找到适合您自己需求的级别.但请记住以下一般建议:

1. 在同一模块中打包在一起的组件(重新)部署在一起.如果其中一个组件的发布频率高于其他组件,那么您可能会通过重复发布未更改的组件来创建超出必要的工作(例如,下游消费者测试),因为它们恰好与更改组件位于同一模块中.
2. 一个人无法部署半个模块.因此,模块中的所有组件都应该密切相关,因此,如果我只能部署此模块中的某些组件,则不要让用户希望...
3. API变化非常缓慢且谨慎,而组件经常变化.出于这个原因和其他原因,API最好部署在他们自己的API包中.请参阅http://wiki.osgi.org/wiki/Separate_API_from_Implementation
4. 为了确保模块内容可以在不破坏用户的情况下进行重构,请始终用Import-Package而不是表达依赖关系Require-Bundle.见http://wiki.osgi.org/wiki/Use_Import-Package_instead_of_Require-Bundle