Convención de nombres de objetos de transferencia de datos Java?

Question

Dado este escenario en el que tiene "Objetos de transferencia" (PoJo con Just Getters/Setters) que pasan una biblioteca de clientes a su API, ¿cuál es la mejor manera de nombrar los objetos de transferencia?

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();
        }
}

En este ejemplo, su clase principal y su objeto de transferencia tienen el nombre Car. Están en diferentes paquetes, pero creo que es confuso tener el mismo nombre. ¿Hay una mejor práctica sobre cómo nombrar los objetos de transferencia?

Answer 1

Generalmente agrego 'DTO' al final del nombre de la clase, así como coloco todos los DTO en su propio paquete. En su ejemplo, lo llamaría com.x.core.dto.cardto.

Answer 2

Data Trescatar Oaturdir las clases deben seguir el Convención de nombres definido en el Especificación del idioma Java:

Los nombres de los tipos de clase deben ser sustantivos descriptivos o frases de sustantivos, no demasiado largos, en caso mixto con la primera letra de cada palabra capitalizada.

ClassLoader
SecurityManager
Thread
Dictionary
BufferedInputStream

[...]

---

Sufijo un nombre de clase con DTO o DTO no es realmente significativo y no cuenta mucho sobre la clase en sí. Considere usar nombres que describan el objetivo de tus clases.

Aquí hay una lista no exhaustiva de sugerencias de nombres que podría usar:

• Algún tipo deDominio
• Algún tipo deConfiguración
• Algún tipo deCartas credenciales
• Algún tipo deDetalles
• Algún tipo deElemento
• Algún tipo deEvento
• Algún tipo deEncabezamiento
• Algún tipo deAporte
• Algún tipo deInstrucción
• Algún tipo deArtículo
• Algún tipo deMensaje
• Algún tipo deMetadatos
• Algún tipo deOperación
• Algún tipo deProducción
• Algún tipo deCarga útil
• Algún tipo deProyección
• Algún tipo deConsulta
• Algún tipo deConsulta
• Algún tipo deRepresentación
• Algún tipo deSolicitud
• Algún tipo deRecurso
• Algún tipo deRespuesta
• Algún tipo deResultado
• Algún tipo deFila
• Algún tipo deAjustes
• Algún tipo deEspecificación
• Algún tipo deEstado
• Algún tipo deResumen

---

^{Nota 1: Ya sean acrónimos o todas las palabras capitalizadas deben manejarse como palabras o no, supongo que depende de usted. Comprobar el API Java y encontrarás algunos tropiezos como ZipInputStream / GZIPInputStream. Ambas clases están en el mismo paquete y la convención de nombre no es consistente. HttpURLConnection Tampoco muestra ninguna consistencia con las acrónimos.}

^{Nota 2: Algunos nombres enumerados anteriormente fueron tomados de este artículo escrito por Richard Dingwall (El artículo original parece no estar disponible, así que Aquí hay una copia en caché desde el archivo web).}

Answer 3

Agregar DTO o DAO o cualquier otra cosa viola seca. El FQN está perfectamente bien, especialmente si realmente son lo mismo.

Answer 4

No creo que haya una mejor práctica o convención para una clase que exhiba este tipo de comportamiento. Personalmente, no me gusta la palabra objeto en ninguno de los nombres de clases. Puede usar alguna calificación como Poko.car o usar una convención de nomenclatura como CAR (para POJO) CARDA (para acceso a datos) Carbiz (para clase de dominio comercial)

O si no le importa el objeto de la palabra en un nombre de clase, busque algo como Cardto (objeto de transferencia de datos del automóvil)

Answer 5

Use una convención que sea adecuada entre las otras convenciones de código que está utilizando. Yo personalmente uso el sufijo "a" (por ejemplo, el objeto de transferencia de datos asociado a la clase de dominio del cliente se llama Customerto). Además, la estructura del paquete debe transmitir la intención de cada tipo de clase (so.foo.domain.customer y so.foo.transport.customerto)