What's wrong about having many packages?

[alzamabar]

Hi, I'm writing an application which has got many different components and those components interact in order to produce the final result. I'll try to explain. I've got a set of interfaces, which I put under the package 'core'. Those interfaces define the contracts for all my component types, that is to say: configuration, filters, externalizers, etc. Since configuration, filter, externalizers, etc are very different kinds of objects, I placed these in different packages (i.e. configuration, filters and externalizers). So now I have the interfaces in 'core' and the implementations in 'configuration', 'filters' and 'externalizers'. I have also got a package specifically for exceptions. Components, Filters and Externalizers make use of each other, and all use the 'exceptions' package.

So I end up having package dependencies. Is that a bad thing? If so why? I find that having the components clearly separated in their own package helps me at development time, since I'm able to quickly find what I'm looking, and also having all the interfaces in one place helps as well. It looks like to avoid package dependencies one shall prefer a bit of confusion.

What's your idea?

[«Midnight»]

Packages are a means to partition 'things' in any way that makes sense. While some methodologies and generators impart special meaning and rules to how packages are organized, this is not part of the UML definition itself.

You appear to have caught the essence of how packages can be used to simplify the presentation of a complex system, ease understanding, and hopefully reduce the chance of errors due to misunderstanding.

Look at the OMG Common Warehouse Metamodel (CWM) for an example of how a complex model can be organized into packages, and how the interdepencies can be constructive. You'll find the model at:http://www.omg.org/technology/cwm/.

David