I've long considered myself a student of Martin's and have studied his OO
design principles, however his package design principle can be a bit
confusing. In the context of his package design principles the term
"package" refers to releasable, binary component such as a DLL or a Jar
file, and not Java packages which are really just a namespace mechanism. He
points this out in his white papers on package cohesion (see Granularity
http://www.objectmentor.com/resources/articles/granularity.pdf ) and he has
also pointed this out in various newsgroup postings
(http://groups.google.com/groups?q=uml+packages&start=10&hl=en&lr=&group=com
p.object.*&scoring=d&selm=pr6v90d3jnud9cf9c7leaoorpi1utt6m8h%404ax.com&rnum=
11). From here out I will use the term "jar", "component" or "binary
package" in reference to Martin's definition of "package" to avoid confusion
with java "namespace packages".

JDepend can be a bit confusing in that it uses Java "namespaces packages" to
perform it's analysis while Martin's definition for "package" refers to
jars; at least in the context of Java. In a way it would make more sense if
JDepend (or any tool that implements Martin's metrics) would examine various
jar files and analyze the dependencies there. After all Martin's package
coupling metrics are about relationships between binary packages and not
about namespace packages.

However JDepend's approach may still be useful. Assuming that one follows a
convention of placing all classes within a given namespace package into a
jar, JDepend may help one to decide how to distribute namespace packages
amongst jars. Again this assumes that the designer is motivated to utilize
multiple jars for reasons such as reuse, division of labor during
development, testability, etc.

Martin's binary package principles indicated that there should be no cycles
of dependencies between binary packages; with this I agree. (I have seen
the nightmares of this violation in the C++ world.) JDepend identifies
cycles between two different namespace packages, but I'm not convinced that
this is necessarily a bad thing. It seems to me that it depends upon
whether the namespace packages are in the same jar or not. If they are in
the same jar then while probably still not ideal, it is something that one
could live with as it does not introduce all of the various problems that
Martin points out because of his definition of package.

Unless people utilizing JDepend fully understand Martin's definition of
packages - and I feel he does not make this point clear enough in his
writings - then they may be mislead by JDepend into thinking that their
package structure needs work when finding cycles among the namespace. Keep
in mind that I'm not writing this so much to criticize JDepend, but rather
gain deeper insight into Martin's metrics and JDepends implementation of
them.

Comments?

Chuck Medcoff
reply/forward to: cmedcoff@... - you must
replace/fix the "."'s