Semantically more appropriate package name than `util` for the following things?

Question

As a strawman consider the package java.util it is a dumping ground for various classes that in most cases do not share anything in common other than the person that put them there was lazy or uninspired to come up with a more semantically correct package name for their class.

As but one example, take the class UUID what would have been a semantically correct package name for that class?

I am working on implementing my own UUID class to be more lightweight. I do not want to use me.myproject.util.UUID for my package name.

I considered me.myproject.rfc4122.UUID but that does not imply the semantic of the use of UUID.

I also considered me.myproject.uuid.UUID but I do not like the tautology in that, even though it is a popular approach in Python to put a class in a module with the same name, and packages in Java are not semantically equivalent to modules in Python.

I also considered me.myproject.UUID but rejected it because I do not want to pollute that part of the namespace with things that are not related. This just moves the problem up a level.

I also considered me.myproject.lib.UUID but this has no more semantic meaning than .util and just renames the problem.

semantics : the branch of linguistics and logic concerned with meaning.

Answer 1

The problem with trying to put each class in a package which has a semantically correct name for that class is that it tends to lead to packages that contain very few classes, or sometimes even just one class. This in turn leads to a multitude of packages.

A more pragmatic approach to package naming is to simply help you find stuff. Keeping frequently used stuff that you always know where to find all bunched up in one place keeps them out of the way and therefore makes it easier to find the more rarely used stuff. So, you do not really need package names which are semantically correct for each one of the classes that they contain, you just need package names which are not semantically incorrect. Obviously, the 'util' package name was chosen according to this line of thinking: it is not the semantically correct name for the classes it contains, but it is also not semantically incorrect, and that's good enough.

So, if this UUID type of yours is destined to only be used by this specific application, (as evidenced by the fact that you are planning to put it under 'myproject',) then it is probably part of the 'model' of your project. You should already have a 'model' package, containing the set of all classes that correspond to your persistent entities, many of which probably have relationships between them, with UUIDs probably being the means of implementing these relationships. Also, your UUIDs probably know how to persist themselves, right? And also, your UUIDs can probably only be found as members of your model entities, right? So, your model package is probably the best place for it.

Otherwise, if this UUID type of yours may be used in other projects too, then it needs to be seen as part of some framework. So, it may live in the root source folder of that framework, or in some 'types' sub-package as MainMa suggested, or even in some sub-package of that framework called 'util' or 'misc'. Nothing wrong with that.

Answer 2

Purpose of packages is to group classes according to some criteria (package by type/layer vs. package by feature etc.). I don't really see a point to create package for just one class - especially if you don't expect there will be other classes in this package in the future.

Also I think that "util" package name is not totally meaningless - it just groups classes by a specific criteria - for me "util" class means that it is not part of the domain of the application, but it's also not a part of the framework (it doesn't influence structure of the application). It's basically just an extension of (non)standard library.

In this case I wouldn't have a problem with putting this UUID class into "util" package. If there will be some other UUID-related utility classes (like separate class for generating UUIDs), it's easy to refactor and create "util.uuid" package for them (unless you're creating a library and UUID will be part of exposed interface, then you need to be a little bit "forward-thinking").

Answer 3

Uncle Bob has some guidelines on package separation.

The first three package principles are about package cohesion, they tell us what to put inside packages:

1. The granule of reuse is the granule of release
2. Classes that change together are packaged together
3. Classes that are used together are packaged together

So, answering your question, who/what is going to use the UUID class, have it as an attribute or invoke operations in it? How is your dependency graph? UUID will be used together with what other classes?

Depending on your answer, maybe you should call it the me.myproject.identity package, the me.myproject.serialization package, me.myproject.DTO or even something else entirely. Maybe, the UUID class should be kept together with your models and you will put it in a package that you already have, like me.myproject.models.

Answer 4

First of all, UUID (with uppercase) seems like a very bad idea for the package name or class name to me, from all the styles enforced one way or another all uppercase names are associated with the "constants". Packages are intended to organise stuff, the easiest way to name a package is by the value of the classes that it holds:

• you may choose to separate the classes by their bussines value, for example com.example.identifier;
• or by their technical value, for example com.example.uuid.

Keep the IT simple