Geek Answers Handbook

Java Package Structure

Best of all, is it normal for interfaces / classes in higher level packets to depend on interfaces / classes in lower level packets?

eg.

may com.company.core.SomeClass depend on com.company.core.apackage.AnotherClass

Or should dependencies go in a different way? I am trying to eliminate loops between packages.

+4
source share
4 answers

Such dependencies are common even in the Java API itself.

Take a look: http://download.oracle.com/javase/6/docs/api/java/awt/image/renderable/package-use.html

You can see that the classes in java.awt use the classes in java.awt.image.renderable .

(ADD) Bottom line: Both directions are used in practice. One is not, IMHO, necessarily better than the other.

+2
source

Typically, a package user might be interested in com.company.functionality.MainUse , which is implemented using com.company.functionality.implementationdetail.FiddleWithStuff , so I would say that you should take dependencies in this direction.

But, probably, another direction is also necessary, since implementation detail classes may require the implementation of interfaces that are part of the interface to functions.

So, unfortunately, I believe that such a strict focus is not a workable way to avoid loops.

+2
source

They usually flow differently. com.mycompany.myproduct.Widget is an interface, and com.mycompany.myproduct.fancy.Button implements it.

There are, however, big exceptions to this general rule, and there is no reason why this should be the rule.

Packages themselves are just folders, with the exception of the rules of primitive access to methods and fields.

What is much more important is the relationship between the bundles, that is (in their basic form) banks. The presence of jar A depends on jar B, depending on jar C, which again depends on jar A, is a real problem. If you have the same circle between packages in the same bank, it can cause disappointment for people who read or debug your code or read it by elitists, but this is not a big problem.

+2
source

Of course, you use the so-called top-down approach , the package depends on its subpackages, but not vice versa.

A bottom-up approach would be the other way around, the package would depend on its parent packages, but not vice versa.

In any case, this is normal if you can maintain consistency, but a top-down approach is simpler and more frequent.

+1
source

More articles:


All Articles