В вашем случае два подхода эффективно эквивалентны.Они оба ограничивают тип аргумента MyObject<...>
или подтипом.
Поскольку ваши примеры методов возвращают void
, нет никакой реальной выгоды от того, чтобы сделать метод универсальным.Единственная важная вещь для вашего метода - это аргумент MyObject<...>
, за исключением того, что реальный тип не имеет смысла.Добавление возможности сделать тип аргумента более конкретным ничего не добавляет для реализации метода и ничего не делает для вызывающей стороны.Другими словами, это не имеет значения "пух".
Так что для ваших примеров, я бы сказал, предпочли не универсальный вариант.Это чище и проще.
Однако, если ваши методы возвращают заданный аргумент вызывающей стороне, то создание общего метода может оказаться полезным;это позволит вам объявить тип возвращаемого значения как T
.Это открывает возможности для вызывающей стороны, такие как цепочка методов или вызов метода «внутри» другого вызова метода, все на основе определенного типа, передаваемого в качестве аргумента.Примером этого в базовой библиотеке может быть Objects.requireNonNull(T)
.
Еще один хороший пример для того, чтобы сделать метод обобщенным, упоминается @Thilo в комментариях:
Другой случай будетесли ваш метод принимает несколько аргументов.Затем вы можете ввести T
, чтобы убедиться, что эти два аргумента имеют один и тот же тип (вместо двух отдельных типов, которые [выполняют] ограничения по отдельности).
Это также может быть применено кодин аргумент, например, Collection<? extends T>
.