How to sort associated classes from different projects

Question

I have a situation where I'm refactoring old code, taking apart an old monster project and splitting it (for various reasons) into smaller sub projects. One project is going to end up containing mostly interfaces while their associated implementations are in another project, and I'm not sure about the best way of setting up the package structure.

Should I go for

org.company.interfaceproject.util.InterfaceClass and
org.company.implementationproject.util.ImplementationClass

or

org.company.project.util.InterfaceClass and
org.company.project.util.ImplementationClass

where the first implementation has the advantage of pointing out to which project the files belong, while the second on doesn't mix in the fact that the files are in different projects at all.

I guess there is no right and wrong here, but I'm curious if anybody has any opinions on the matter.

Answer 1

Both have merits. It ultimately depends on you intentions for the project. If your intent is to eventually create alternate implementations of the interfaces it may make more sense to go with option 1. If this will be the only implementation of the interfaces option 2 would be more reasonable.

Answer 2

If you can you should put the interface clases into a seperate plugin/package. When you use interfaces you most of the time will have more than one implementation of this interface.

I would prefer option 1

Answer 3

Sun has Naming conventions. For packages:

The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981.

Subsequent components of the package name vary according to an organization's own internal naming conventions. Such conventions might specify that certain directory name components be division, department, project, machine, or login names.

So I would prefer the second option where you specify project name. Or I would merge both like this:

org.company.project.interfacepackage.util.InterfaceClass and
org.company.project.implementationpackage.util.ImplementationClass

Answer 4

Yes you need to just come up with a naming convention. Usually a combination of both has suited our company to avoid ambiguity. For example, say you had an interface:

org.company.service.UserService

Then, we would use the following for the implementation class that was wired by, or had, spring dependencies:

org.company.service.spring.UserServiceImpl

This then has the best of both viewpoints:

1. You have the classes cleanly in a separate package
2. Using this class name convention, it's clear that its an implementation of UserService, and still distinguishable even when both packages are imported.

Answer 5

Mostly agree with Clinton.

Ultimately, each package name is an island as far as Java is concerned, but it can be handy to segregate things according to what gets assembled with what at build time, as in:

com.foo.client.*
com.foo.server.*
com.foo.common.*

Mostly this keeps your ant filesets simple. Note that this applies even if the layout of source files is quite different, due to the way things get built or whatever. The only thing I would say is be careful not to get the same package in more than one source directory! That can be ugly and is easy to do by accident.

So unless that kind of thinking pushes you to create separate high-level packages, I like the style of putting the implementation package inside the interface package, giving the impl package a name that suggests how it is specialized, and of naming the implementation FooImpl. You almost never need to import multiple implementations, but you occasionally do want to import both the interface and impl, and in that case it's nice if they have a similar name.