La "classe dati" è davvero un odore di codice?

Question

Il libro di Fowler Refactoring elenca "Classe di dati" come odore di codice. Tuttavia, quando l'unità testa un metodo, passando oggetti valore, ad es. oggetti di trasferimento dati, rendono il test molto più facile che provare a impostare o esaminare lo stato all'interno di una classe.

Mi sembra che la metodologia Test Driven Development si basa sull'idea che test facili da scrivere sono un'indicazione che l'interfaccia è pulita e il metodo è coeso. I metodi puramente idempotenti sono i più facili da testare e il più facile da riutilizzare. Allora, perché una classe di dati è una brutta cosa? La correzione consigliata è spostare il comportamento nella classe dati, ma perché un oggetto valore deve avere un comportamento?

Answer 1

Non penso che le classi di dati siano identiche agli oggetti valore. Gli oggetti valore sono in genere immutabili, come Lunghezza o Denaro. Le "classi di dati" a cui Fowler fa riferimento sembrano modelli di dominio anemici, vale a dire borse di getter e setter.

Quindi, è possibile passare un oggetto valore a un metodo, ma sicuramente non a modelli di dominio anemici. Questo perché il metodo avrà indebito vantaggio nel mutare più cose - e molto probabilmente violare il modello di responsabilità singola.

il caso di classi di dati non modificabili:

In tal caso, mi consiglia di avere uno strato di mapping che sarebbe mappare le entità condivise per un ricco modello di dominio e viceversa. Il tuo codice si occuperà prevalentemente dei modelli di dominio ricchi. L'idea non è di sovraccaricare eccessivamente le tue classi di servizio con troppa logica aziendale, in quanto sarebbe dannoso per il riutilizzo del codice e la testabilità. Naturalmente, il design è più un'arte - e non c'è solo un nero e un bianco. Le classi di dati sono indispensabili come DTO o entità condivise non modificabili, come hai detto. Ma un design robusto basato sul dominio li userebbe con parsimonia e minimizzerebbe la loro impronta sul codice base.