Java package conventions and interface implementations?

[enlightenedby42]

Was wondering if someone could give me a few pointers on structuring java packages.

What I'm needing to do is create data wrapper objects for database entities for use in a handful of web apps we're working on. The nature of the business is really windows applications for trucking companies to manage their insurance claims and human resources stuff. All the web stuff will be extensions of this functionality (largely for the purpose of varying forms of data exchange such as interfaces to insurance companies for claim submission, etc.)

As such, there's are some pretty clear commonalities between the different flavors of similar data I'd need to be representing that provide good opportunities for polymorphism via interface implementations (I think my OO terminology is correct there).

By way of example, say I want to create an interface or possibly even an abstract class containing method definitions for fetching common data from comman places in the DB (or some implementations in the latter case) for a very basic claim containing, say, a claim number, an occurrence date, and anything else that is common to all claims of all types.

So, then I can create a WorkersCompClaim that implements the interface or abstract class to add government mandated nature of injury codes and such to my existing code. Or add product information in a CargoClaim class. Why reinvent the wheel on fields that are common to all derivatives of an insurance claim?

So in the above example, how would those abstract classes or interfaces fall into the package structure?

Would the interface and it's implementation be on the same "level" in the package structure, or would the derived class be "underneath" the interface?

In other terms, should the package:

com.mycompany.dataobjects.claims

contain both the interface and its implementation?

Or should the above contain the interface, and have a subpackage along the lines of:

com.mycompany.dataobjects.claims.workerscomp

which contains a worker's comp implementation of the base interface/abstract class?

Am I thinking about this stuff correctly in the first place even?

Sorry for the length....trying to be clear and am new at this.

Thanks.

 

[tim_m]

generally i would say that a package probably wouldn't have a single class in it. packages are for organization/grouping of related classes so unless you have several classes related to workerscomp (so many that it might be cumbersome to lump them all in claims) or you think you will create more in the future, i would probably not make a sub-package.

 

[Wingy]

I would say your workers comp should go in the claims package, and not the sub package.

Without me going and looking through some doc (It's been a little while), See how the standard packages work, and follow that convention. I'm sure there's an example in there somewhere of what you want to do.

Off the top of my head, I think of SWING and Listener interfaces, then the concrete examples??? If there are any..

 

[devman]

Just for example, my convention for packaging (its mostly arbitrary you can really do whatever you like) is TLD.company.location.project.projectpackages

One thing to keep in mind when your structuring your packages is that any other class in the package can access an object or class static fields with protected or default modifiers (not private though).

generally I find it better to put abstract classes in packages at higher levels (although packaging isn't hierarchical at all.) just for the sake of organization.

If you want a general idea of how your structuring your packages and classes you can use a tool such as JDepend. There is even an ant task (if you use ant) that can make use of JDepend for you.