Los DTO se utilizan ampliamente y "resuelven" problemas reales, ¿verdad?

Problemas

• Objeto anémico
• Datos inconsistentes
• Lógica duplicada
• Estructura duplicada
• clase contaminante
• Violación de ocultación de información
• Código repetido entre mutadores , accesores, serializadores , analizadores
• efecto dominó
• Integridad de los datos

1. Transferir datos anémicos en matrices.
2. Utilice objetos comerciales reales.
3. Si queremos transferir objetos parciales: use proxies u objetos nulos para romper el gráfico de referencia.

Equivocado

Derecha

Detección

Podemos utilizar los mismos detectores de objetos anémicos.

Podemos buscar clases anémicas sin comportamiento de objeto comercial (eliminación de serializaciones, constructores, mutadores, etc.).

Etiquetas

• Anémico

Los DTO son una herramienta y una práctica establecida en algunos idiomas. Debemos usarlos con cuidado y responsabilidad.

Si necesitamos desmontar nuestros objetos para enviarlos fuera de nuestros reinos, debemos tener mucho cuidado. Dado que los objetos desmembrados no tienen consideraciones de integridad.

Su autor nos advierte sobre su abuso real.

Relaciones

Code Smell 01 — Modelos anémicos Code Smell 13 — Constructores vacíos Code Smell 20 — Optimización prematura Code Smell 28 — Setters

Más información

Los mejores olores son los que son fáciles de detectar y la mayoría de las veces te llevan a problemas realmente interesantes. Las clases de datos (clases con todos los datos y sin comportamiento) son buenos ejemplos de esto. Los miras y te preguntas cuál debe ser el comportamiento en esta clase.

Martín Cazador

Grandes citas de ingeniería de software

Este artículo es parte de la serie CodeSmell.

Cómo encontrar las partes apestosas de su código