jdeveloper skrev:
Are there best practices guidelines for package or namespace
hierarchies? (other than :don't make too many of them)
Starting with a developer setup.
If I wanna start under my project directory: c:\jwork
what would be the best practices for creating and placing source code
package hierarchies?
There is, firstly, a common practice of reversing your web-address and
using it as the root of your package hierarchy. So if you thinking of
developing a banking system, and your home page is
www.jdeveloper.com,
then your package hierarchy will begin (for example):
com.jdeveloper.bank
I don't know of any common guidelines for directory arrangement (and it
can be dictated by your frameworks/tools anyway), but a good starting
point would be:
c:\jwork\src - holds source code (the first class conceivably will be
in c:\jwork\src\com\jdeveloper\bank)
c:\jwork\class - holds generated .class files
c:\jwork\test - holds unit-tests/test-classes
Your packages, secondly, must reflect your program; or rather, they
must reflect the largest-grained encapsulation you desire with your
application; so if your banking program has a lot of functionality
related to clients, then it'll probably have a client package; if it
has a data-layer the hides data-base specifics, it will probably have a
data package; etc.
You could then have a flat package structure, like:
com.jdeveloper.bank.client
com.jdeveloper.bank.data
com.jdeveloper.bank.presentation
com.jdeveloper.bank.service
etc.
If you choose to then have hierarchies, then you are moving from a
one-dimensional, flat structure, and entering into a two-dimensional
space. In this case, you should first identify what you mean by having
one package in another: what is the difference between having two
packages, "Side-by-side," in the hierarchy, and having two packages in
a, "Parent-child," relationship?
Different people have very different views on this: it can be useful to
download a few sourceforge projects and look at their package
hierarchies, just to get a feel (of course, you may not agree with what
you see). What matters is that you have a reason for structuring it the
way you do; whether that reason is right or wrong (again, a matter of
choice sometimes) will evolve as your programming does.
For what's it's worth, an example:
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs70.html
..ed