Comments on: Enforcing acceptable package dependencies in your build http://www.magpiebrain.com/blog/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/ Sam Newman's blog Fri, 21 Nov 2008 20:32:39 +0000 http://wordpress.org/?v=2.6.3 By: Sam Newman http://www.magpiebrain.com/blog/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-807 Sam Newman Thu, 07 Jul 2005 12:49:50 +0000 http://www.magpiebrain.com/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-807 Thats good to know - thanks Pat. That also implies that rolling an Ant plugin capable of failing the build shouldn't be too much bother. Thats good to know - thanks Pat. That also implies that rolling an Ant plugin capable of failing the build shouldn’t be too much bother.

]]> By: Pat http://www.magpiebrain.com/blog/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-806 Pat Thu, 07 Jul 2005 12:11:29 +0000 http://www.magpiebrain.com/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-806 Another way that we've been tying JDepend into our build is to use it programatically as a unit test which will fail our build process. Although there was probably a little bit more work involved in setting up failures (and formatting the info well), we still managed to get it going with not too much hassle. Another way that we’ve been tying JDepend into our build is to use it programatically as a unit test which will fail our build process. Although there was probably a little bit more work involved in setting up failures (and formatting the info well), we still managed to get it going with not too much hassle.

]]> By: Sam Newman http://www.magpiebrain.com/blog/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-805 Sam Newman Thu, 07 Jul 2005 08:41:12 +0000 http://www.magpiebrain.com/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-805 I'd certainly agree that some circular dependencies can show up classes that should be in the same package - but equally they can show you places where you need to decouple things to achive high cohesion within a package (that is the package is strongly focused with common responsibilities) and low coupling. Again, there is an informative discussion of cohesion and coupling on the "c2 wiki(c2Wiki - Coupling and cohesion)":http://www.c2.com/cgi/wiki?CouplingAndCohesion. I’d certainly agree that some circular dependencies can show up classes that should be in the same package - but equally they can show you places where you need to decouple things to achive high cohesion within a package (that is the package is strongly focused with common responsibilities) and low coupling. Again, there is an informative discussion of cohesion and coupling on the “c2 wiki(c2Wiki - Coupling and cohesion)”:http://www.c2.com/cgi/wiki?CouplingAndCohesion.

]]> By: Laird Nelson http://www.magpiebrain.com/blog/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-804 Laird Nelson Thu, 07 Jul 2005 00:43:10 +0000 http://www.magpiebrain.com/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-804 Thanks for the response. You raise good points. It's interesting—I'm aware of the architectural problems in general (if A depends on B and B depends on A, changes to one often necessitate changes to the other), but where A and B are packages and not classes I don't necessarily see this as being as big a deal. Often it really means that the classes that cause the interdependency should simply be in the same package, or that the two packages should be collapsed, since you're going to have to deploy them with each other anyhow. I'll check out the c2 links. Thanks again. Thanks for the response. You raise good points. It’s interesting—I’m aware of the architectural problems in general (if A depends on B and B depends on A, changes to one often necessitate changes to the other), but where A and B are packages and not classes I don’t necessarily see this as being as big a deal. Often it really means that the classes that cause the interdependency should simply be in the same package, or that the two packages should be collapsed, since you’re going to have to deploy them with each other anyhow. I’ll check out the c2 links. Thanks again.

]]> By: sam newman http://www.magpiebrain.com/blog/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-803 sam newman Wed, 06 Jul 2005 21:10:01 +0000 http://www.magpiebrain.com/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-803 Using the Java API as a model of good programming is probably not good idea - the API developers have admitted on many occasions that mistakes were made, but due to maintaining backwards compatibility have been unable to fix them. Circular dependencies are a problem for _any_ language - Java is no exception (for more on package coupling and OO, see the "Pricnciples of Object Oriented Design":http://www.c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign. If A depends on B, and B depends on A, if you change A you can potentially change B, which in turn can force a change on A. More importantly, A and B are now inextricably linked - the larger the project, the more this becomes a problem - as changes cannot be isolated to a single package the chance for effects rippling out to affect others increases (for a much better description see pages 6 onwards of the "Granularity":http://www.objectmentor.com/resources/articles/granularity.pdf article linked to from the C2 wiki page on "Acyclic Dependencies":http://www.c2.com/cgi/wiki?AcyclicDependenciesPrinciple) Using the Java API as a model of good programming is probably not good idea - the API developers have admitted on many occasions that mistakes were made, but due to maintaining backwards compatibility have been unable to fix them.

Circular dependencies are a problem for _any_ language - Java is no exception (for more on package coupling and OO, see the “Pricnciples of Object Oriented Design”:http://www.c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign. If A depends on B, and B depends on A, if you change A you can potentially change B, which in turn can force a change on A. More importantly, A and B are now inextricably linked - the larger the project, the more this becomes a problem - as changes cannot be isolated to a single package the chance for effects rippling out to affect others increases (for a much better description see pages 6 onwards of the “Granularity”:http://www.objectmentor.com/resources/articles/granularity.pdf article linked to from the C2 wiki page on “Acyclic Dependencies”:http://www.c2.com/cgi/wiki?AcyclicDependenciesPrinciple)

]]> By: Laird Nelson http://www.magpiebrain.com/blog/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-802 Laird Nelson Wed, 06 Jul 2005 20:47:12 +0000 http://www.magpiebrain.com/2005/07/06/enforcing-acceptable-package-dependencies-in-your-build/#comment-802 I really do not intend this to be a naive question, so kindly hear me out. Are circular dependencies really bad in Java? Don't they happen all the time? They're all over the JDK itself (util depends on io which depends on io, to take but one arbitrary example). I would think with the runtime binding that—apart from architectural concerns, which, I grant you, are often quite valid—circular dependencies just aren't that big a deal, technically. I really do not intend this to be a naive question, so kindly hear me out. Are circular dependencies really bad in Java? Don’t they happen all the time? They’re all over the JDK itself (util depends on io which depends on io, to take but one arbitrary example). I would think with the runtime binding that—apart from architectural concerns, which, I grant you, are often quite valid—circular dependencies just aren’t that big a deal, technically.

]]>