Should Java class name duplicate package name? [closed]

Question

I'm thinking about what is the best practice in Java for the following case:

I have a logic in my program that I want to put in a separate package.

For example (my current case), it is a logic that will collect some statistics and later send them to server). So my package under my project com.example.project will be named com.example.project.statistics.

There will be some classes inside the package, in this case StatisticsDispatcher (basically container and manager for events) and StatisticsEvent (event that should be calculated into statistics).

The question is, what naming convention should I use? I see two options:

1. StatisticsDispatcher and StatisticsEvent like mentioned above. The class name makes clear what the class does, but is a bit verbose in the absolute name, like com.example.project.statistics.StatisticsEvent.
2. Dispatcher and Event. It is shorter and the purpose of the class is clear from its absolute name, like com.example.project.statistics.Dispatcher , but later on in the code these names can be ambiguous with other packages' classes and even if not, when I import these classes in the beginning of a file, class names like "Dispatcher" and "Event" are very general and in the middle of a file it will not be evident what are they related to.

I haven't found any mention about this when googling java package and class naming conventions. I'm afraid the first option will be correct, but I really don't like the verbosity in the package name and the class name, so I want to ask you, other programmers, how do you solve such cases.

Thanks in advance

Answer 1

I would prefer to be explicit (and perhaps verbose) to being concise (and perhaps ambiguous).

Your example re. Dispatcher / Event is a good one. If you're unlucky, you'll end up having to fully qualify each occurrence of these to resolve any ambiguities.

In such a scenario you'll end up either with a lot of verbose code, or restructuring your code such that conflicting classes don't co-exist (conflicts may actually act as an indicator that unrelated entities are co-existing, but that's another discussion)