namespace hierarchy best practices

Thread view:

jdeveloper - 17 Jul 2006 05:20 GMT

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?

Reply to this Message

Ed - 17 Jul 2006 08:45 GMT

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

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html

Reply to this Message

Mark Space - 17 Jul 2006 16:53 GMT

> jdeveloper skrev:
>
[quoted text clipped - 10 lines]
> then your package hierarchy will begin (for example):
> com.jdeveloper.bank

Besides this, I've also seen package use the name of their project or
product as the root of a package. For example, if you make a product
for Java developers name SuperLibrary, the your package is named
superlibrary, and everything is under there

import superlibrary.supercomponent;
import superlibrary.utils.superutility;

//etc...

Just make sure no one is using the same name, and you'll probably be ok.

As an aside, I've often wondered if there should a convention for people
who don't have their own domain names to release under. Let's say you
have a project at Source Forge. You could release your package under:

import net.sourceforge.projects.myproject.*;

This would require cooperation from the domain name owner. They should
specify where collaborations or codehaus projects get released under
their hierarchy, and how an individual project name is determined and
made unique. Most codehaus projects already have a way of making the
project name unique, so they'd just have to specify where the project is
released.

Any interest you think? Or overkill?

Reply to this Message

jdeveloper - 17 Jul 2006 20:29 GMT

Wow, great feedback from both of you.
Mark: Not overkill at all, but a very relevant direction.

I'd interested in more feedback on this. Merely googling about codehaus
and sourceforge projects has given me lots of meaningful info.

Thank you Ed and Mark

> > jdeveloper skrev:
> >
[quoted text clipped - 37 lines]
>
> Any interest you think? Or overkill?

Reply to this Message

namespace hierarchy best practices

Free Magazines