Devo creare interfacce per oggetti di trasferimento dati?

La risposta generale è no , perché non devi mai aggiungere codice senza uno specifico motivo concreto e non c'è una ragione generale per tale interfaccia.

Detto questo, a volte può esserci una buona ragione. Ma in tutti i casi che ho visto, queste interfacce erano parziali, coprendo solo una o poche proprietà condivise da più classi che volevo usare polimorficamente senza dare loro una superclasse comune. I candidati tipici sono una proprietà Id da utilizzare in una sorta di registro o una proprietà Name da visualizzare all'utente. Ma può essere utile in ogni caso in cui desideri che il codice gestisca tutto ciò che ha una X - crea solo un'interfaccia XSource che contenga i metodi getX (e, solo se richiesto, setX ).

Ma un'interfaccia separata per ogni classe di modello, contenente tutte le proprietà? Non riesco a immaginare una buona ragione per farlo. Una cattiva ragione sarebbe un quadro mal progettato che lo richiede; I bean di entità hanno fatto proprio questo, se non ricordo male. Per fortuna erano così male che non hanno mai ottenuto molta trazione e sono deprecati da EJB 3.0

Sidenote: per favore evita di usare il termine "oggetto valore" per descrivere i bean Java con getter e setter banali - in conflitto con la definizione più comune di value object come qualcosa senza identità che è solitamente immutabile. Un termine migliore sarebbe DTO o model class - sebbene in quest'ultimo caso si noti che i modelli di dominio anemico sono considerati antipattern.

Le interfacce definiscono un contratto tra le classi che implementano le interfacce e i loro client. Sono usati come un meccanismo di astrazione in modo che i clienti possano manipolare "cose che hanno un determinato comportamento".

Quindi la risposta generale alla domanda "dovrei creare e utilizzare questa interfaccia?" è: Sì, se puoi associare un concetto (uno solo) semanticamente rilevante ai tuoi clienti.

Ad esempio, Comparable è una buona interfaccia, perché spiega che le cose possono essere confrontate grazie a uno dei loro metodi, e come cliente sono interessato a trattare oggetti comparabili (ad es. ordinandoli). A contrario, CoolStuff non è una buona interfaccia se ammetti che gli oggetti cool non hanno un comportamento specifico (in effetti, puoi immaginare un software in cui avere a che fare con oggetti interessanti ha senso, perché hanno un comportamento comune come un metodo beCool .

Nel tuo caso particolare, credo che la tua interfaccia sia inutile. Chi lo userà, come e quando? Non è possibile creare un'interfaccia per ciascuno dei valori mutabili. Quindi chiediti qual è la proprietà pertinente e interessante dietro ai tuoi metodi.

Se quello che vuoi è occuparsi di oggetti che hanno tutti i loro valori mutabili accessibili attraverso un paio di metodi, dai un'occhiata alla nozione di bean Java e al modo in cui puoi forzare le tue classi ad adottare le loro convenzioni.

Come ha detto Michael, non aggiungere un'interfaccia a meno che tu non ne abbia una necessità specifica.

Il test è un esempio di una buona ragione. Anche se preferisco usare veri collaboratori se sono solo "oggetti valore" come li chiami, per un vero isolamento del test dell'unità potresti aver bisogno di creare un oggetto falso per il test, nel qual caso un'interfaccia è molto utile.

Se vuoi che questo oggetto abbia una sorta di convalida dei campi in futuro, dovresti incapsularli nelle fasi iniziali.

Creare l'interfaccia è ok, ma NON il modo in cui funziona l'esempio. Dovresti rimuovere il setter dall'interfaccia, e andrà tutto bene:

interface ValueObject {
  String getName();
};

Ciò consente molte implementazioni diverse di esso, come il nome può essere recuperato dal database ... Setter dovrebbe essere nell'interfaccia differente.

L''interfaccia per oggetto valore' è ciò che sono abituato a chiamare un accessor.

Ho sperimentato diverse politiche in merito alle necessità degli utenti. Alcune persone difendono quando il più possibile, altre vietano quindi di ridurre la quantità di codice da scrivere.

Alcuni rationnal per gli accessor (o l'utilizzo diretto del valore) sono i seguenti:

• Gli accessori consentono di cambiare in seguito il modo in cui il valore è memorizzato
• Gli accessori consentono di aggiungere il registro di accesso quando si desidera eseguire il debug del software (quando si aggiunge una chiamata di registro in un unico metodo, si acquisiscono tutte le modifiche di valore)
• Gli accessor sono più in linea con la programmazione degli oggetti, ogni variabile viene incapsulata dai metodi
• Gli Accessors riducono l'espressività del codice (più SLOC per lo stesso risultato)
• Gli accessor hanno un po 'di CPU

Personalmente sostengo di ridurre il numero di accessor e di usarli quando ti aspetti che il setter (setName) diventi più che una semplice influenza successiva.

Questo tipo di oggetto valore è piuttosto basso. Suggerirei di spingerlo in una delle due direzioni: (1) rendere il valore oggetto immutabile, cioè come un valore reale o, (2) elevare la mutevolezza a un dominio di livello superiore orientato funzione aziendale, nel senso che dovremmo esporre le interfacce in termini di unità di funzionalità rilevanti per il dominio.