Best Practices for extending utility classes in java

Question

I've extended classes from apache-commons-3 to add my own utility functions which are unavailable in them. e.g.:

public class CollectionUtils extends org.apache.commons.collections.CollectionUtils
{
        /**
     * Similar to collection.contains(member) except just doesn't throw NPE when set is null, simply returns false
     * @param collection
     * @param member
     * @return
     */
    public static <K> boolean contains(Collection<K> collection,K member)
    {
        return collection!=null && collection.contains(member);
    }
}

This solved my purpose of using my functions & commons functions through same class CollectionUtils.

But, Apache has removed extendibility in version 4 by introducing private constructors in the utility classes. There is also a discussion on the same here.

Now, my code is breaking if I upgrade to version 4. What are the best practices to extend utility classes to add custom/specific utility methods?

score 6 · Answer 1 · answered May 29 '17 at 12:50

Although I voted close as "opinion based" I wanted to give you some input.

As it is already said in your linked discussion, extending utility classes is a bad practice in the first place. The change in the version 4 probably aims at that convention.

Extending utility classes (with static methods only) makes no sense, since you can't overwrite static methods anyway. You can, however, hide them. This means that this might happen accedentally with unintended behaviour. So it has a risk with no real value. It doesn't really make your code more complicated if you just use two utility classes. There even is a compiler warning for not accessing static methods directly.

What are the best practices to extend utility classes to add custom/specific utility methods?

To summarize: The best practice is not to extend them but to use a second custom utility class.

Re: "It doesn't really make your code more complicated if you just use two utility classes.": 2 is more complicated than 1. You now need to search for the method in 2 places. Code-completion is less useful. Where extension is possible, you can also alias the library to something short (e.g.: StringU, StrU, or even SU), as long as its understood by those working on the code. (Static imports can mitigate this, but can also end up causing more confusion, since then there's no class name). You could delegate, but that's more maintenance. Also: Generally, you don't want to override, just add. — mconner, Aug 07 '19 at 15:47

Best Practices for extending utility classes in java

1 Answers1