15

Me and my R&D team maintain a large codebase. We've divided our business logic into multiple packages. some of which have classes with identical names.

As you can guess, the names conflict when both classes are referenced in the same Java file.

For example:

com.myapp.model (package)
 - Device (class)
 - ...

com.myapp.data (package)
 - Device (class)
 - ...

We had a debate on what's the best practice to treat these cases and the following options came up:

1st Option

  • Renaming the class, adding a prefix

    ModelDevice
DataDevice

2nd Option

  • Using the full package+class name when both are referenced 

    com.myapp.model.Device
com.myapp.data.Device

What's more correct in terms of code management and scalability?

we are currently mixing both approaches and starting to have inconsistency

Jossef Harush Kadouri
  • 273
  • 1
  • 3
  • 9
  • If it's occasional it probably does not matter - if it is a recurring pattern I would probably name the classes more precisely to prevent it from becoming a mess. – assylias Jan 17 '16 at 23:39
  • You have no idea how much I loath `java.util.Date` and `java.sql.Date` - especially since `java.sql.Date` is a subclass of `java.util.Date` and so nicely slips out of data layers (and doesn't serialize nicely to JSON). –  Jan 19 '16 at 19:16
  • Option 2.1 *Always* use the fully qualified name, even if the other is not referenced – Caleth Oct 19 '18 at 14:34

3 Answers3

21

Use the package name. This type of problem is precisely why Java uses the package naming convention that it does. It prevents these sorts of problems, whether it's two teams in the same company or two teams on opposite sides of the earth.

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89
3

Just to add one aspect that hasn't been mentioned yet:

Have a look at the usage patterns, i.e. the Java sources that reference one or both classes.

IMHO, in the majority of cases, source files should reference only one of the conflicting classes, and from the context it should be clear whether they deal with the model or the data world. If that's difficult for any reason, I'd rename the classes, as I generally don't like package-prefixed class names in source code (it degrades readability).

If you have source files that deal with both worlds, they might be bridging classes with the resonsibility to translate between two different views of the world, and here I'd prefer to find package-prefixed class names.

But seeing both Device classes in one source might as well be a hint that the source violates the single-responsibility principle by mixing tasks from the model and the data world.

Ralf Kleberhoff
  • 5,891
  • 15
  • 19
2

As of now you have one ModelDevice class (Device in the model package). What if you have another such ModelDevice for a different classification? The problem may still persist and the overheads will also continue to increase.

Though for the time being you may find that renaming classes be of some good help, for a long run the suggested alternate is to go by prefixing the package names, which is what the Industry Standard.

itsraghz
  • 131
  • 3