Dans certaines interfaces que j'ai écrites, j'aimerais nommer des paramètres de type génériques avec plus d'un caractère pour rendre le code plus lisible.
Quelque chose comme....
Map<Key,Value>
Au lieu de cela...
Map<K,V>
Mais en ce qui concerne les méthodes, les paramètres de type ressemblent à des classes Java, ce qui est également déroutant.
public void put(Key key, Value value)
Il semble que Key et Value soient des classes. J'ai trouvé ou pensé à quelques notations, mais rien de tel qu'une convention de Sun ou une meilleure pratique générale.
Alternatives que j'ai devinées ou trouvées ...
Map<KEY,VALUE>
Map<TKey,TValue>
Oracle recommande ce qui suit dans Tutoriels Java> Génériques> Types génériques :
Conventions de dénomination des paramètres de type
Par convention, les noms des paramètres de type sont des lettres majuscules simples. Cela contraste fortement avec les conventions de la variable naming que vous connaissez déjà, et pour une bonne raison: sans cette convention, il serait difficile de faire la différence entre une variable de type et une classe ou une interface ordinaire prénom.
Les noms de paramètres de type les plus couramment utilisés sont:
- E - Element (largement utilisé par le Java Framework Framework)
- K - Clé
- N - Nombre
- T - Type
- V - Valeur
- S, U, V etc. - 2e, 3e, 4e types
Vous verrez ces noms utilisés tout au long de l'API SE Java SE et le reste de cette leçon.
Je m'en tiendrai à cela pour éviter la confusion entre les développeurs et les mainteneurs possibles.
Type
Une bonne discussion peut être trouvée dans les commentaires sur la page DZone, Conventions de dénomination pour les types paramétrés .
Voir le commentaire d'Erwin Mueller. Sa suggestion est parfaitement évidente pour moi: Ajoutez le mot Type
.
Appelez un Apple un Apple, une voiture une voiture. Le nom en question est le nom d'un type de données, non? (In OOP , une classe définit essentiellement un nouveau type de données.) Appelez-le donc un "Type".
Exemple de Mueller, tiré de l'article de l'article d'origine:
public interface ResourceAccessor <ResourceType, ArgumentType, ResultType> {
public ResultType run (ResourceType resource, ArgumentType argument);
}
T
Une question en double fournit cette réponse par Andy Thomas. Notez l'extrait du guide de style de Google qui suggère qu'un nom de type à plusieurs caractères devrait se terminer par une seule majuscule T
.
Oui, vous pouvez utiliser des noms à plusieurs caractères pour les variables de type, tant qu'ils sont clairement distingués des noms de classe.
Cela diffère de la convention suggérée par Sun avec l'introduction des génériques en 2004. Cependant:
Dans certaines interfaces que j'ai écrites, je voudrais nommer un paramètre de type générique avec plus d'un caractère pour rendre le code plus lisible.
La lisibilité est bonne.
Comparer:
public final class EventProducer<L extends IEventListener<E>,E>
implements IEventProducer<L,E> {
à:
public final class EventProducer<LISTENER extends IEventListener<EVENT>,EVENT>
implements IEventProducer<LISTENER, EVENT> {
ou, avec la convention multi-caractères de Google:
public final class EventProducer<ListenerT extends IEventListener<EventT>,EventT>
implements IEventProducer<ListenerT, EventT> {
public final class EventProducer<ListenerT extends IEventListener<EventT>,EventT>
implements IEventProducer<ListenerT, EventT> {
Google Java autorise les noms à une seule lettre et les noms de classe à plusieurs caractères se terminant par T.
5.2.8 Noms des variables de type
Chaque variable de type est nommée dans l'un des deux styles:
Une seule majuscule, éventuellement suivie d'un seul chiffre (tel que
E
,T
,X
,T2
)Un nom sous la forme utilisée pour les classes (voir Section 5.2.2, Noms de classe ), suivi de la lettre majuscule T (exemples:
RequestT
,FooBarT
).
"Sans cette convention, il serait difficile de faire la différence entre une variable de type et un nom de classe ou d'interface ordinaire." - tiré des Tutoriels Oracle, "Types génériques"
Les noms à un seul caractère ne sont pas le seul moyen de distinguer les paramètres de type des noms de classe, comme nous l'avons vu ci-dessus.
Pourquoi ne pas simplement documenter la signification du paramètre de type dans le JavaDoc?
Il est vrai que le @param
Les éléments JavaDoc peuvent fournir une description plus longue. Mais il est également vrai que les JavaDocs ne sont pas nécessairement visibles. (Par exemple, il existe une aide au contenu dans Eclipse qui affiche les noms des paramètres de type.)
Les noms de paramètres de type multi-caractères ne respectent pas la convention Oracle!
De nombreuses conventions originales de Sun sont suivies presque universellement dans la programmation Java.
Cependant, cette convention particulière ne l'est pas.
Le meilleur choix parmi les conventions concurrentes est une question d’opinion. Dans ce cas, le choix d'une convention autre que celle d'Oracle est mineur. Vous et votre équipe pouvez choisir une convention qui répond le mieux à vos besoins.
Vous pouvez utiliser javadoc pour donner au moins un indice aux utilisateurs de votre classe générique. Je n'aime toujours pas ça (je suis d'accord avec @ chaper29) mais la documentation aide.
par exemple,
/**
*
* @param <R> - row
* @param <C> - column
* @param <E> - cell element
*/
public class GenericTable<R, C, E> {
}
L'autre chose que l'on sait faire est d'utiliser mon IDE pour refactoriser une classe en rompant la convention. Ensuite, travailler sur le code et refactoriser en lettres simples. Cela me facilite la tâche de toute façon si les paramètres de type sont utilisés.
La raison pour laquelle la convention de dénomination officielle recommande d'utiliser une seule lettre est la suivante:
Sans cette convention, il serait difficile de faire la différence entre une variable de type et un nom de classe ou d'interface ordinaire.
Je pense qu'avec les IDE modernes, la raison n'est plus valable comme par exemple. IntelliJ Idea affiche des paramètres de type génériques avec des couleurs différentes de celles des classes normales.
Code de type générique tel qu'affiché dans IntelliJ Idea 2016.1
En raison de cette distinction j'utilise des noms descriptifs plus longs pour mes types génériques, avec la même convention que les types réguliers. J'évite d'ajouter des préfixes et des suffixes tels que T ou Type car je les considère comme un bruit inutile et plus nécessaire pour distinguer visuellement les types génériques.
Remarque: Comme je ne suis pas un utilisateur d'Eclipse ou de Netbeans, je ne sais pas s'ils offrent une fonctionnalité similaire.