Convention de nommage d'objet de transfert de données Java?
Compte tenu de ce scénario où vous avez des "objets de transfert" (POJO avec juste des getters/setters) qui sont passés par une bibliothèque cliente à votre API, Quelle est la meilleure façon de nommer les objets de transfert?
package com.x.core;
public class Car {
private String make;
private String model;
public Car(com.x.clientapi.Car car) {
this.make = car.getMake();
this.model = car.getModel();
}
}
Dans cet exemple, votre classe principale et votre objet de transfert ont tous deux le nom Car
. Ils sont dans des paquets différents mais je pense qu'il est déroutant d'avoir le même nom. Existe-t-il une meilleure pratique sur la façon de nommer les objets de transfert?
5 réponses
J'ajoute généralement 'DTO' à la fin du nom de la classe et place tous les DTO dans leur propre paquet. Dans votre exemple, je l'appellerais com.x.de base.dto.CarDTO.
D ATA Transfer oLes classes bject doivent suivre la convention de nom définie dans la spécification du langage Java :
Les noms des types de classes doivent être des noms descriptifs ou des phrases nominales, pas trop longs, en cas mixte avec la première lettre de chaque mot en majuscule.
ClassLoader SecurityManager Thread Dictionary BufferedInputStream
[...]
Le suffixe d'un nom de classe avec DTO ou Dto n'est pas vraiment significatif et ne en dire beaucoup sur la classe elle-même. Pensez à utiliser des noms qui décrivent le but de vos classes.
Voici une liste non exhaustive de suggestions de noms que vous pourriez 1: {[6] } que les acronymes ou tous les mots en majuscules doivent être traités comme des mots ou non, je suppose que c'est à vous de décider. De vérifier la API Java et vous trouverez certains trébuche comme ZipInputStream
/ GZIPInputStream
. Les deux classes sont dans le même paquet et la convention de nom n'est pas cohérente. HttpURLConnection
ne montre aucune cohérence avec les acronymes non plus.
Note 2: certains noms énumérés ci-dessus ont été empruntés à cet article écrit par Richard Dingwall (l'article original semble ne plus être disponible, donc voici une copie en cache de L'Archive Web).
Ajouter DTO ou DAO ou toute autre chose viole DRY. Le FQN est parfaitement bien, surtout s'ils sont vraiment la même chose.
Je ne pense pas qu'il existe une meilleure pratique ou convention pour une classe présentant ce genre de comportement. Personnellement, je n'aime pas le mot Objet dans l'un des noms de classe. Vous pouvez soit utiliser une qualification comme Poko.Voiture ou utiliser une convention de nommage comme Voiture (pour POJO) CarDa (pour l'accès aux données) CarBiz (pour la classe de domaine d'affaires)
Ou si cela ne vous dérange pas le mot objet dans un nom de classe, optez pour quelque chose comme CarDto (Car Data Transfer Object)
Utilisez une convention qui convient parmi les autres conventions de code que vous utilisez. Personnellement, j'utilise le suffixe " TO " (par exemple, L'objet de transfert de données associé à la classe de domaine Client s'appelle CustomerTO). En outre, la structure du paquet doit transmettre l'intention de chaque type de classe (so.foo.domaine.Client.foo.transport.CustomerTO)