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

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.