Custom Java utility package

A common operation in my current project is converting a string version of an IP address int开发者_C百科o an integer representation, and it's easily handled by a single static method. I would normally try to keep this as close to the code that uses it as possible, but it's also needed in completely different parts of the application.

Since it seemed harmful to have classes in very different packages referring to each other for this one utility function, I created a util package and moved the static methods (one for int to String, one for String to int) into an Ip class in that package.

I recognize that this is probably a sign that I should rethink the project's organization, but is there anything harmful about adding a package to hold project-wide utility functions? Is there a standard way to handle this situation in Java?

---

It's a generic problem, not just Java.

"Since it seemed harmful" - what's the harm? Coupling? Single point of failure?

You have an example of exactly what you did in the JDK itself: java.util has lots of classes that are used all over the place.

I think your design is defensible. Keep it that way until experience tells you a better place to put that class.

The one thing you should guard against is cyclic dependencies. Don't have anything in your util package depend on any of its dependencies. Break cycles with interfaces if you must.

---

I don't see anything wrong with that. As a matter of fact, if you find you have multiple such specific operations that belong in the same problem domain and aren't all conveniently available in third-party libraries, or you wish to avoid adding additional dependencies on external code, you may very well turn this into a separate project. A utils jar of your own for reuse throughout your apps could be good to have around.

As far as I can tell, you did the exact right thing by identifying a piece of code that will be reused and placing it somewhere separately for that purpose.

---

Personally I would have done something similar to what you have done. I usually create a util package in the base package for project wide utility functions that I know are going to be used throughout my project.

If I need a utility function that is only used by a specific class, the class itself can handle it. If I need a utility that will be used by classes in a specific package, create a util package in that one.

Just my two cents.

---

is there anything harmful about adding a package to hold project-wide utility functions?

Not really. util packages exist for a reason, to hold util classes.

Especially when it is useful across other packages. So it can be a logical sequence for your classification

---

I don't know if it's "correct" but I think I've probably had some type of utility package in every project I've ever worked on.

---

I'd just like to add "high fan-in" as a term for such utility classes. From Code Complete (2nd Ed.) referring to it as one of several "desirable characteristics of a design":

High fan-in refers to having a high number of classes that use a given class. High fan-in implies that a system has been designed to make good use of utility classes at the lower levels in the system.

---

a utility class is a class that defines a set of methods that perform common, often re-used functions. Most utility classes define these common methods under static scope. Examples of utility classes include java.util.Collections which provides several utility methods (such as sorting) on objects that implement a Collection. Utility classes should always be final and have a private constructor.