Is it ok to extend utilities?

Question

Apache Commons has StringUtils. It's great, but I wish it had a shuffle() method or similar

Is it ok to create my own StringUtils that extends Apache's StringUtils and adds the method (Apache's class is not final)? That way, I will get the best of both worlds

// something like this
    public static CharSequence shuffled(CharSequence originalSequence) {
        List<Character> characters = originalSequence.chars()
                .mapToObj(c -> (char) c)
                .collect(Collectors.toList());
        Collections.shuffle(characters, random);
        StringBuilder shuffledSequence = new StringBuilder();
        characters.forEach(shuffledSequence::append);
        return shuffledSequence;
    }

However, extending utilities feels fishy. For example, if Apache's class adds the shuffle() method at some point (or shuffled()), I may get an unwanted hiding on update. It's not likely it's going to break anything, and we're not upgrading the artifact version any time soon, but it's still something to consider

I obviously don't want to wrap and write (or even generate) a ton of delegating methods

What is the best way forward?

Answer 1

I don't think there's any justification for extending a util class like that - or even if extending has any technical meaning for a static class with static utils.

Let's say you do create your own MyStringUtils with the new shuffled method, your usage will look something like this contrived example, which uses both your method and a standard one:

import my.almost.apache.MyStringUtils;

public static void shuffleUntilSurprised(CharSequence seq) {
   while (!MyStringUtils.endsWith(seq, "?!")) {
      seq = MyStringUtils.shuffled(seq);
   }
}

As you can see, you use the same static class name for both methods, which keeps your func relatively clear, but can introduce complications later on, as you say, if StringUtils ever adds conflicting methods, but also makes anyone reading your code have to check whether MyStringUtils.endsWith is really the same as StringUtils.endsWith, or whether there's any overrides involved.

This is the alternative, if you create a completely separate class for your shuffled method, without touching the Apache class:

import org.apache.commons.lang3.StringUtils;
import my.really.not.apache.MyStringUtils;

public static void shuffleUntilSurprised(CharSequence seq) {
   while (!StringUtils.endsWith(seq, "?!")) {
      seq = MyStringUtils.shuffled(seq);
   }
}

The difference is that endsWith and shuffled are called from different classes, but the code is no less clear, has no dependency issue with future updates to StringUtil, and is clear to anyone familiar with Apache StringUtil what is going on.

My suggestion? Just create a new class for your new static helpers, and use Apache for the existing ones, side by side.

Answer 2

It's a weighing of concerns, but I would extend it.

1. It's where it belongs conceptually - that's the StringUtils type for string utils
2. You implement it in a way you expect StringUtils to behave and implement it if it were to
3. If StringUtils ever implements it you can drop your own - now the same concern is provided natively
4. If StringUtils ever implements it and causes you a conflict (duplicate declaration error) that's an intentional side effect that forces you to clear up (instead of now having two util types and two shuffle methods and subsequently both being used, hopefully with same or acceptably similar behavior)
5. You FIND the method through intellisense/completion when you access/type StringUtils. instead of requiring project domain knowledge
6. You don't have to import additional, different namespaces for string utility, to find string util types, or string util methods

From a system design, component concern viewpoint it belongs into StringUtils.