Gli oggetti modello hanno interfacce?

Question

Sto creando il modello di dominio nel mio sistema. Quando si progettano i miei oggetti modello, dovrei creare interfacce per ciascun oggetto entità? Le persone mi hanno detto che il nostro livello web non dovrebbe preoccuparsi dell'implementazione di un'entità e dovremmo essere in grado di sostituire le implementazioni, ma non sono sicuro che ciò accadrà mai.

Per esempio, se abbiamo una classe insegnante che mantiene un elenco di studenti, il metodo getStudents potrebbe essere:

public List<Student> getStudents() { 
     return this.students; 
} 

o questo:

public List<Student> getStudents() { 
    return someExternalService.retrieveStudents(); 
} 

ho capito questo beneficio, ma qual è la pratica generale?

Answer 1

A meno che non si abbia una buona ragione per pensare che sarà necessario sostituire il modello, non me ne preoccuperei ancora. Basato sul principio YAGNI (You ain't gonna need it)

Answer 2

Nessuno dei progetti che abbia mai visto o partecipato ha avuto interfacce per le entità di dominio.

Ma in uno dei miei progetti ho avuto interfaccia NamedEntity:

public interface NamedEntity { 
    int getId(); 
    String getName(); 
} 

Tutte le entità del dominio implementato questa interfaccia. Mi ha dato la possibilità di non creare diversi convertitori jsf per entità diverse ma creare un convertitore che usasse questa interfaccia al posto delle classi di dominio concreti.

Answer 3

Non posso parlare di pratica generale, ma non si tratta quasi di nascondere l'implementazione.

Si tratta di formalizzare l'interfaccia come base per documentazione e contratti.

In astrazione dei modelli in interfacce, si sta creando documentazione per gli sviluppatori di client di servizi. A seconda del tuo stile di sviluppo, potresti avere o meno una descrizione formale del tuo servizio (ad es. Una descrizione basata su WSDL). Le interfacce possono soddisfare questa esigenza.

Answer 4

La mia opinione generale è che vorrei non creare un insieme one-to-one di interfacce per i modelli di dominio, poiché ciò non fa altro che duplicare la struttura di classi del modello di dominio. Non aggiunge nulla di utile.

I due casi mi viene in mente subito dove ho sarebbe considerare interfacce presentiamo è:

1. un'interfaccia descrive il contratto/comportamento di alcuni set di classi nel modello di dominio, in cui è utile modello che il comportamento in modo indipendente delle classi che implementano
2. è necessario esporre il modello di dominio per clienti esterni e vogliono nascondere i dettagli implementativi da loro

In altre parole, aggiungi interfacce se ti aiutano a descrivere il comportamento o ti aiutano a nascondere i dettagli di implementazione dai client. Altri motivi potrebbero essere validi, ma quelli sono quelli che vengono in mente.

Answer 5

Penso che ci sia una differenza importante tra l'avere un'interfaccia per il servizio per recuperare l'oggetto e l'oggetto del modello stesso.

In fase di esecuzione, il servizio per caricare un oggetto modello può differire in base al luogo in cui si richiedono i dati. Ma il formato e il tipo di oggetto dati attesi non cambiano, indipendentemente da come si crea questo oggetto. Pertanto gli oggetti del modello che trasportano lo stato non necessitano di un'interfaccia, ma le classi di servizio per creare e caricare questi oggetti modello necessitano dell'interfaccia.

L'unico motivo per cui gli oggetti del modello dispongono di interfacce avrebbe senso se l'oggetto del modello non è solo un semplice oggetto di tipo bean ma oggetto che espone anche un qualche tipo di comportamento.

Answer 6

L'estrazione di un'interfaccia è uno dei più semplici rifacimenti; Nel peggiore dei casi è un nome di classe -> metodo di spostamento. Lo sforzo di cambiare idea, una volta trovato un motivo per farlo, è minimo. Ho sempre trovato che se una decisione è facile da cambiare, rinforza ancora YAGNI e KISS. La contro-argomentazione è che non è molto difficile creare inizialmente un'interfaccia, il che è vero, ma la manutenzione si aggiunge nel tempo se la decisione viene presa più volte, spesso non utilizzata.