Как я могу расширить статический финальный класс утилит гуавы?

Question

Когда я использовал общие коллекции, я сделал пользовательские расширения для этих утилит, такие как:

class MyCollectionUtils extends CollectionsUtils {
static myutilityMethod()
static removeDublicate(..)
static myPredicate(...)
}

В этом случае у меня есть все функции из CollectionsUtils и мои методы расширения только с одним импортом!

В гуаве все классы статических утилит final.

Каков наилучший подход для расширения API сбора гуавы?Например, новый распространенный предикат, фабрика коллекций и т. Д., Объединитель коллекций.

Answer 1

За один почему ответ, читаемость. Теперь читателю нужно знать все о вашем служебном классе, даже о методах, которые просто перенаправляют в Guava.

ArrayList<String> myStrings = MySpecialLists.newArrayList();

Это стандартный ArrayList или специальный список, который я инициализировал значениями по умолчанию? Даже если я знаю Гуаву от и до, я не могу знать ответ, пока не изучу ваш API. И клиентский код не может гарантировать, что он останется простой версией Guava (возможно, вы перестанете наследовать от Guava и просто реализуете все методы списка самостоятельно).

Answer 2

Поскольку все методы являются статическими, расширение служебного класса на самом деле не предлагает никакого значения, кроме возможности получить все за один импорт.

Мне кажется, проще всего создать собственный класс утилит, который не расширяет класс Guava, и просто импортировать класс guava, когда вам это нужно (с дополнительным оператором import). Наличие нескольких операторов импорта не плохо; с любой компетентной IDE вам вряд ли придется управлять ими самостоятельно.

Если вы действительно хотите, то написанный вами служебный класс может обернуть методы guava, но это просто создаст больше способов обслуживания, так как вам придется обновлять свои методы, когда меняются методы guava. .

Answer 3

Мы разработали эти статические служебные классы специально для предотвращения их расширения.

Для начала, вы не можете расширять классы статических утилит, даже если они не являются окончательными, потому что они не предоставляют конструкторы. (Вы получите ошибку компилятора, что конструктор по умолчанию не может быть использован.)

Импорт дешевый. Продолжай и используй два.

Answer 4

Я не думаю, что вы все равно должны использовать наследование в вашем примере со статическими утилитами.Расширяющиеся классы должны быть зарезервированы для случаев, когда вам действительно нужно смоделировать некоторый тип родительско-дочерних отношений.Количество импорта не является достаточной причиной, чтобы отказаться от хорошего стиля.