Temporary "junk" Packages Are A Best Practice
At the beginning of a project it is hard to find good names for packages--there are only a few classes to package and usually you are still in the phase of grasping the domain knowledge.
Particularly hard to find are good package names for classes with infrastructural responsibilities. In the first iterations class names and their packages are constantly refactored. A chance to find perfect name and home for all classes is negligible.
Instead of using generic, but good sounding names like,
framework, a really bad sounding name like "waste", "junk" or "unrelated" does a better job by forcing you to refactor such a "kitchen sink" package with its contents in a later iteration.
Kitchen-sink "util" packages with un-cohesive contents have a far better chance of surviving a code review, than an intentionally "bad" named package like "waste" or "sink".
[See also an in-depth discussion in the "Real World Java EE Patterns--Rethinking Best Practices" book (Second Iteration, "Green Book"), page 420 in, chapter "Pragmatic Java EE Architectures"]
See you at Java EE Workshops at MUC Airport (already sufficient registrations, so the workshop will absolutely take place)!
that is a pretty good idea. In my recent projects I had the same problems and did many package refactoring sessions within the first iterations. Most of the time, when a class is moved to "common", this is where it remains forever, since the package name doesn't bother you enough to make things change :) IDE support for those "junk" packages would be nice, too... rendering the package in some awful color for example.
Posted by Tim Brückner on January 08, 2013 at 01:48 PM CET #
This is a really good practice. You can also extend this practice to anything that has a name, be it a class or a method. It should let you avoid XHelper or YUtility generic names and get meaningful ones.
Posted by Nicolas Fränkel on January 08, 2013 at 05:42 PM CET #
So why not simply place every single class in one package like com.example and move to more specialized packages when this kitchen sink package starts to grow and clusters of common classes emerge?
Posted by Tomek N. on January 08, 2013 at 10:50 PM CET #
a good point. This is what I actually do with "essential entities". I place the most important entities at the beginning of a project into packages with the same name. E.g. a Order entity resides in the "order" package.
thanks for your comment!,
Posted by Adam Bien on January 08, 2013 at 11:16 PM CET #
It's a good point, but no matter what you do, you always end up with *some* utility code. Convenience operations on Strings/Dates/Collections and the like. How do you suggest dealing with those?
Posted by Nim on January 09, 2013 at 06:20 PM CET #
"...How do you suggest dealing with those?"
You will probably get multiple classes responsible for String operations, Dates and particularly collections.
Then I would name the package strings, dates and collections :-)
If you get exactly these three unrelated classes, it would be o.k. to use a "util" package for that purpose. But I would limit the size of this package to exactly three. It should not grow over time...
Posted by Adam Bien on January 09, 2013 at 07:42 PM CET #
I sometimes I make the wrong assumption at design time about where package's should beloaded, so having a junk package will help
Posted by Hlulani Mhlongo on October 19, 2013 at 10:29 AM CEST #