L'ID commerciale noto di un'entità deve essere rappresentato con un tipo dedicato in DDD / OOP?

9

In termini pratici significa usare un'usanza (immutabile) classsu uno stringo qualche altro tipo primitivo.

Esempi:

Pubblicazione: numero di libro standard internazionale.
Finanza: numero di identificazione internazionale dei titoli.

vantaggi:

Può garantire il formato di un identificatore.
Diventa un membro di prima classe del modello.

svantaggi:

Aggiunge attrito di persistenza (ad es. Entity Framework).
Più codice.

— tana
fonte

Dovresti usare una classe personalizzata? Sicuro. Dovresti usarli come ID? Assolutamente no :) Un documento identificativo con un significato aziendale causerebbe problemi lungo la strada.

— Songo,

2

@Songo Per me questo è un argomento secondo cui gli ID dovrebbero avere una semantica di valore , ma i tipi primitivi non sono gli unici tipi con semantica di valore, quindi ciò non esclude necessariamente le classi imo. Sentiti libero di pubblicare una risposta in competizione anche se ho dimenticato di fare questo punto.

— Ixrec,

1

Una mia vecchia domanda ha toccato l'argomento con opinioni diverse: programmers.stackexchange.com/questions/281827/… Sono andato con la creazione dei tipi e continuo a farlo.

— Ziv,

6

Se riesci a fornire alla classe funzionalità abbastanza utili da giustificare la complessità aggiunta di non essere una stringa, allora fallo. Per identificatori come ISBN e ISIN, sospetto che non sia così.

Perché una classe di identificatori sia utile, mi aspetto che assomigli a qualcosa del genere:

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

Se invece sembra più così:

class ISIN {
    getString()
    setString()
}

Quindi abbandonerei completamente la classe, userei stringhe regolari ovunque e mi assicurerei di usare costantemente "isin" in tutti i nomi delle variabili rilevanti.

Nota che in alcune lingue, l'aggiunta di un nuovo tipo non ha quasi "complessità aggiunta" nei programmi tipici, nel qual caso verrai incoraggiato a creare il nuovo tipo anche se non aveva alcuna funzionalità. Ma questo non è il caso della maggior parte dei linguaggi OOP tradizionali come il C ++.

— Ixrec
fonte

6

Direi di provarci. Direi che in questo caso i vantaggi superano gli svantaggi. È probabile che il codice aggiuntivo sia piuttosto minimo e il problema della persistenza può essere risolto abbastanza facilmente fornendo una sorta di convertitore tra la tua nuova classe e il tipo che il database si aspetta (non ho mai usato Entity Framework ma so che questo è relativamente indolore in Hibernate).

Uno dei vantaggi che puoi ottenere definendo la tua classe è che il compilatore può garantire che tutti i metodi che desiderano un codice ISBN o ISIN lo sappiano in fase di compilazione se provi a passare il valore sbagliato. Sarà anche molto più difficile sovrascrivere accidentalmente quel campo nella tua entità. Possiamo evitare del tutto errori comuni come questo:

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

Se il codice ISBN è una classe anziché un tipo primitivo, il codice sopra riportato non verrà nemmeno compilato, risparmiando molto tempo di debug in seguito.

— Matt Watson
fonte

1

setter e getter? È il 1992?

— Miles Rout,