A princípio vc pode usar qualquer nome, então nada impede que se faça algo assim:
public interface NomeExemplo<Type extends ExemploSuperVO, AnotherType, SomeOtherType>
Até existe uma convenção de se usar nomes com apenas uma letra:
-
E
(Elemento): usado nas classes de collections - List
, Set
, etc)
-
K
(Key) e V
(Value): usado em mapeamentos (Map
é o mais conhecido)
-
N
(Número)
-
T
(Type): um tipo qualquer, sem significado especial
-
S
, U
, V
etc. - segundo, terceiro e quarto tipos, etc
Existem ainda outros, como R
para “resultado” (no caso das classes do pacote java.util.function
, que retornam um resultado de determinado tipo), A
para “acumulador” (usando em algumas operações de streams - exemplo) e por aí vai.
Convenções são úteis, e se for quebrá-las, deve ter um bom motivo. Parafraseando o final desta resposta:
…a escolha das convenções a seguir fica a seu critério no fim das contas. No caso da nomenclatura de identificadores, vejo pouco motivo para fugir da convenção vez que, embora ela de fato poderia ter sido melhor, você já vai estar utilizando um monte de classes e métodos de bibliotecas que seguem a convenção padrão (até mesmo os do pacote java.lang), o que significa que ao tentar ir contra isso, você acabaria criando um código com um estilo heterogêneo e despadronizado.
… Apenas pense nos prós e contras de cada abordagem antes de tomar uma decisão e seja lá qual for a decisão tomada, seja consistente e coerente nela.
Dito isso, existe também o Google Java Style Guide, que sugere que se use o sufixo T
no final, para indicar que aquilo é um tipo genérico. Por exemplo:
public interface NomeExemplo<SuperVoT extends ExemploSuperVO, OutroT, MaisOutroT>
Pra mim, isso não tem a ver com “a melhor prática”. Tem que avaliar os prós e contras, ver o que faz sentido no seu caso e tomar a decisão que parecer melhor.
Se for algo padronizado, bem documentado e combinado com o time, não vejo problema nenhum. O que não pode é cada um fazer de um jeito, que aí vira bagunça…