By lower level package I mean a package a.b.c.d and by higher level package I mean a.b.c and I've used the terms in relation to each other. I'm not sure if there's a terminology for defining such levels. However, from object oriented perspective, I wanted to know if it is a good idea to call a.b.c.d.aClass.aMethod() from a.b.c.anotherClass.anotherMetod(). In my opinion, a.b.c should be designed such that it is unaware of the package a.b.c.d since a.b.c.d represents either a more concrete form of a.b.c or something that logically comes below a.b.c.
views:
33answers:
1
+3
A:
In any case, it is not advised to make dependencies between packages go both ways. So if you have a dependency from package a.b.c to a.b.c.d, you shouldn't have any dependencies from a.b.c.d to a.b.c. This is known as package tangling, which generally indicates high coupling and possibly broken layering of the application. Tools like Sonar can help you find package tangling.
I generally put interfaces of my API in the higher level packages and implementations in the lower level packages. So references will go from lower level packages to higher level packages.
If your API resides in a lower level package, you should reorganise your packages.
Stijn Van Bael
2010-07-09 10:43:52
+1 for noting the dependency inversion principle
Dave
2010-07-12 22:54:23