¿Debería representarse la identificación comercial conocida de una entidad con un tipo dedicado en DDD / OOP?

9

En términos prácticos, significa usar una costumbre (inmutable) classsobre uno stringu otro tipo primitivo.

Ejemplos:

Publicación: Número internacional estándar del libro.
Finanzas: número de identificación internacional de valores.

Ventajas:

Puede garantizar el formato de un identificador.
Se convierte en un miembro de primera clase del modelo.

Desventajas

Agrega fricción de persistencia (por ejemplo, Entity Framework).
Más código

— Guarida
fuente

¿Deberías usar una clase personalizada? Por supuesto. ¿Deberías usarlos como ID? Absolutamente no :) Una identificación con un significado comercial causaría problemas en el camino.

— Songo

2

@Songo Para mí, ese es un argumento de que los ID deben tener semántica de valor , pero los tipos primitivos no son los únicos tipos con semántica de valor, por lo que eso no necesariamente descarta las clases imo. Sin embargo, siéntase libre de publicar una respuesta competitiva ya que olvidé hacer ese punto.

— Ixrec

1

Una vieja pregunta mía tocó el tema con diferentes opiniones: programmers.stackexchange.com/questions/281827/… Fui con la creación de los tipos y continúo haciéndolo.

— Ziv

6

Si puede proporcionar a la clase suficiente funcionalidad útil para justificar la complejidad añadida de no ser una cadena, entonces hágalo. Para identificadores como ISBN e ISIN, sospecho que este no es el caso.

Para que una clase de identificador sea útil, esperaría que se vea así:

class ISIN {
    fromCUSIP()
    fromRawISINString()
    toString(ISIN::FormatType)
    getExchange()
    getCountryCode()
    getLastFourDigits()
    getWhateverCode()
    ...
}

Si en cambio se parece más a esto:

class ISIN {
    getString()
    setString()
}

Luego abandonaría la clase por completo, usaría cadenas regulares en todas partes y me aseguraría de usar consistentemente "isin" en todos los nombres de variables relevantes.

Tenga en cuenta que, en algunos idiomas, agregar un nuevo tipo casi no tiene "complejidad añadida" en los programas típicos, en cuyo caso se le recomendaría crear el nuevo tipo incluso si no tuviera ninguna funcionalidad. Pero este no es el caso para la mayoría de los lenguajes OOP tradicionales como C ++.

— Ixrec
fuente

6

Yo diría que lo haga. Yo diría que las ventajas son mayores que las desventajas en este caso. Es probable que el código adicional sea bastante mínimo y el problema de persistencia se puede resolver con bastante facilidad al proporcionar algún tipo de convertidor entre su nueva Clase y el tipo que espera la base de datos (nunca he usado Entity Framework pero sé que esto es relativamente indoloro en Hibernar).

Una de las ventajas que puede obtener al definir su propia clase es que el compilador puede asegurarse de que cualquier método que desee un ISBN o un ISIN lo sepa en el momento de la compilación si intenta pasar el valor incorrecto. También será mucho más difícil sobrescribir accidentalmente ese campo en su entidad. Podemos evitar errores comunes como este por completo:

book.setAuthor(otherBook.getAuthorName());
book.setIsbn(otherBook.getAuthorName());
book.setPrice(otherBook.getPrice())

Si ISBN es una clase en lugar de un tipo primitivo, el código anterior ni siquiera se compilará, lo que ahorrará mucho tiempo de depuración más adelante.

— Matt Watson
fuente

1

setters y getters? ¿Es 1992?

— Miles Rout