Question

These functions may be hard to fit into a specific class,

what’s the best practice to deal with them?

Answer 1

I suppose you mean methods instead of functions? You should really imagine the word static doesn’t exist in Java world, there really isn’t a case where static would actually do you anything good in the long run.

I’m actually currently facing a similar problem, I have a whole bunch of API methods I want to give out for users to meddle with but I want to hide the actual methods underneath to hide the implementation details.

The problem of course is that if I just cram everything into one class, it becomes humongous and hard to use even with the best autocompletion tools available. The problem you have most likely really isn’t about where to put those methods but how to present them to the user.

To solve that I’d suggest you create a hierarchy of objects where you access your helper methods by calling myUtil.someGroup().someMethod(param1, param2); This is actually how some API:s already work, for example popular Web framework Apache Wicket is configured by using Settings object which uses composition to allow itself to have multiple groups of distinct features.

To really flesh out this from theory to a working example, lets assume you have a bunch of image manipulation methods which either transform the image’s dimensions or change its properties like color, brightness and contrast. Instead of having this:

public class ImageUtil {

    public static BufferedImage adjustHue(float difference,
                                          BufferedImage original) {
        /* ... */
        return adjusted;
    }

    public static BufferedImage adjustBrightness(float difference,
                                                 BufferedImage original) {
        /* ... */
        return adjusted;
    }

    public static BufferedImage adjustContrast(float difference,
                                               BufferedImage original) {
        /* ... */
        return adjusted;
    }

    public static BufferedImage setHeight(int newHeight,
                                          BufferedImage original) {
        /* ... */
        return adjusted;
    }

    public static BufferedImage setWidth(int newWidth,
                                         BufferedImage original) {
        /* ... */
        return adjusted;
    }

}

you should instead have these interfaces to describe each set of operations:

public interface IImageColorOperations {

    BufferedImage adjustHue(float difference, BufferedImage original);

    BufferedImage adjustBrightness(float difference, BufferedImage original;)

    BufferedImage adjustContrast(float difference, BufferedImage original);

}

public interface IImageDimensionOperations {

    BufferedImage setHeight(int newHeight, BufferedImage original);

    BufferedImage setWidth(int newWidth, BufferedImage original);

}

and an accompanying separate class for each interface which you instantiate in your "main" image utility class like so:

public class ImageUtils {

    private final IImageDimensionOperations dimension;
    private final IImageColorOperations color;

    public ImageUtils() {
        this(new ImageDimensionOperations(),
             new ImageColorOperations());
    }

    /**
     * Parameterized constructor which supports dependency injection, very handy
     * way to ensure that class always has the required accompanying classes and
     * this is easy to mock too for unit tests.
     */
    public ImageUtils(IImageDimensionOperations dimension,
                      IImageColorOperations color) {
        this.dimension = dimension;
        this.color = color;
    }

    /* utility methods go here */

}

But wait, this isn’t all! There’s now two paths to go, you can decide for yourself which one you’d like to take.

First, you can use composition to expose the interface methods directly:

public class ImageUtils implements IImageDimensionOperations,
                                   IImageColorOperations {

    private final IImageDimensionOperations dimension;
    private final IImageColorOperations color;

    public ImageUtils() {
        this(new ImageDimensionOperations(),
             new ImageColorOperations());
    }
    /* etc. */
}

With this, you just need to delegate the calls to various methods to the actual operation class. Downside to this is that if you add another method, you have to modify both this utility class and the underlying implementation class.

Your second choice is to expose the operation classes themselves directly (that’s why I added those finals there!):

public class ImageUtils {

    public final IImageDimensionOperations dimension;
    public final IImageColorOperations color;

    public ImageUtils() {
        this(new ImageDimensionOperations(),
             new ImageColorOperations());
    }    

    public ImageUtils(IImageDimensionOperations dimension,
              IImageColorOperations color) {
        this.dimension = dimension;
        this.color = color;
    }

    /* Nothing else needed in this class, ever! */

}

by doing this you get those nice looking calls such as

BufferedImage adjusted = imageUtils.color.adjustHue(3.2f, original);

and when you add some method to either of the interfaces, you already have them available in your image utility class without any additional modification. Yes, generally public fields are a big no-no in Java, however I do think that in this case that’s not such a bad thing, especially with the finals marking the fields as unmodifiable (at least in theory).