Ho letto molti articoli recentemente che descrivono Primitive Obsession come odore di codice.
Ci sono due vantaggi nell'evitare l'ossessione primitiva:
-
Rende il modello di dominio più esplicito. Ad esempio, posso parlare con un analista aziendale di un codice postale anziché di una stringa che contiene un codice postale.
-
Tutta la convalida è in un posto anziché nell'intera applicazione.
Ci sono molti articoli là fuori che descrivono quando si tratta di un odore di codice. Ad esempio, posso vedere il vantaggio di rimuovere l'ossessione primitiva per un codice postale come questo:
public class Address
{
public ZipCode ZipCode { get; set; }
}
Ecco il costruttore del codice postale:
public ZipCode(string value)
{
// perform regex matching to verify XXXXX or XXXXX-XXXX format
_value = value;
}
Romperebbe il principio DRY mettendo la logica di validazione ovunque sia utilizzato un codice postale.
Tuttavia, per quanto riguarda i seguenti oggetti:
-
Data di nascita: verifica che la data sia maggiore di mente e inferiore alla data odierna.
-
Salario: controlla che sia maggiore o uguale a zero.
Vuoi creare un oggetto DateOfBirth e un oggetto Stipendio? Il vantaggio è che puoi parlarne quando descrivi il modello di dominio. Tuttavia, si tratta di un caso di over engineering in quanto non vi è molta convalida. C'è una regola che descrive quando e quando non rimuovere l'ossessione primitiva o dovresti farlo sempre se possibile.
Aggiorna Credo che potrei creare un alias di tipo invece di una classe, il che aiuterebbe con il punto uno sopra.