Granularity of Component-Based Architectures

Although I'm a Java developer and this is question concerns OSGi and modularity according to Java, the question really applies for any object-oriented, 3GL.

I'm beginning to grasp the concepts of truly "modular" development and beginn开发者_Go百科ing to take a real liking to OSGi. For the first time ever I'm beginning of thinking of deploying jars in very granular, reusable, specialized deployments. However this new mode of thinking has stirred up a few questions.

In pure component-based architectures, does every class get jarred up? If not how granular should components be? Is it possible to make every component reusable?

What are some "rules of thumb" to use when determining how granular a modular component should be? Thanks in advance!

I'm going to answer this mostly from an OSGi perspective.

IMHO it's important to distinguish between components and modules. A component is a programming artefact: something that has behaviour and may offer services to other components. In implementation terms, you program a component using one of OSGi's component models such as Declarative Services. See http://wiki.osgi.org/wiki/Component_Models_Overview

A module is a deployment artefact: it is the packaging of components and/or APIs into an artefact that can be copied around and installed in various runtimes. Therefore implicitly you can package multiple components in one module, OR create one module per component.

The fact is, module contents are quite easy to refactor, so you shouldn't worry too much up front about the granularity: as you get more experience with OSGi you will find the right level for your own needs. However bear in mind the following general advice:

1. Components packaged together in the same module are (re)deployed together. If one of those components is being released more frequently than the others then you may be creating more work than necessary (e.g., testing by downstream consumers) by repeatedly releasing unchanged components, just because they happen to be in the same module as the changing component.
2. One cannot deploy half a module. Therefore all the components in a module should be closely related, so you do not make users wish "if only I could deploy just some of the components in this module"...
3. APIs change very slowly and cautiously, whereas components change frequently. For this and other reasons, APIs are best deployed in their own API bundles. See http://wiki.osgi.org/wiki/Separate_API_from_Implementation
4. In order to ensure module contents can be refactored without breaking users, always express your dependencies in terms of Import-Package rather than Require-Bundle. See http://wiki.osgi.org/wiki/Use_Import-Package_instead_of_Require-Bundle