Passaggio e restituzione dell'oggetto dominio nel metodo di creazione

Question

Passaggio e restituzione dell'oggetto dominio nel metodo di creazione

#1 da (1 voti)
#2 da (0 voti)

1

Abbiamo questo bean con due proprietà:

ContainerImage
    + name (final, not null)
    + id (null)

Poi c'è questo metodo:

ContainerImage create(ContainerImage containerImage);

Riceve ContainerImage con name e senza id ; e restituisce nuovo ContainerImage con id popolato, come risultato dell'operazione di underlaying.

Per me, questo ha un cattivo odore; perché l'input semplicemente non usa il id , quindi perché dovrei passarlo? Inoltre, non cambia l'oggetto in entrata, che va anche bene, ma qualcuno potrebbe aggiungere la modifica, che non voglio.

La mia proposta è di avere un'interfaccia di sola lettura per ContainerImage che non richiede il id , che verrà utilizzato per l'argomento di input, ad esempio:

ContainerImageData
    + name

Questo ha senso per te?

P.S. Sto parlando di Java ora, ma la domanda è piuttosto generale.

Modifica

Il metodo create crea immagini di finestra mobile, quindi è un metodo che funziona con l'API remota della finestra mobile, in più potrebbe fare alcune cose da parte. Ma mi piacerebbe pensare a questa domanda senza sapere cosa realmente fa, solo dal lato API.

immutability java interfaces

posta igor 25.05.2016 - 12:49

fonte

2 risposte

Leggi altre domande sui tag immutability java interfaces

Perché la funzionalità ORM persist () usa i riferimenti per popolare insert_id e non restituisce? È un enumeratore onnicomprensivo appropriato?

score 1 · Answer 1

Non c'è niente di sbagliato nell'usare POJOs o TO ( oggetti di transazione ) per informare un insieme specifico di campi. Aiuta anche a disaccoppiare i livelli.

È comune ai livelli superiori come controllo o azienda per diversi motivi:

Questi livelli non vogliono esporre la reale struttura dei dati.
Questi livelli vogliono fornire modi specifici / semplici per informare i dati.
Coloro che consumano questi livelli possono o non possono sapere quanto sia reale la struttura dei dati ( entità ).
POJO rendono questi livelli agnostici alla struttura reale dei dati. Questo è utile quando l'origine dati è fuori dal tuo controllo o manutenzione, quindi non essere troppo dipendente da tali dati. POJO agisce come una linea difensiva che protegge la tua azienda da modifiche indesiderate.

Quindi ContainerImageData che ha lo scopo di fornire un set specifico di campi necessari per creare una voce, si adatta bene alla definizione e agli utilizzi di TO.

Apportando alcune modifiche, nel tuo caso, vorrei andare a:

ContainerImage create(AddContainerImageTO to){
     ContainerImage container = new ContainerImage(to.getName());
     <dao>.create(container);
     return container;
}

Giusto per garantire che AddContainerImageTO abbia lo stato giusto, vorrei fornirlo con un costruttore specifico e solo getter .

AddContainerImageTO{          
      AddContainerImageTO(String name){...}
      String getName(){...}
}
//Note: I didn't provide setters for a good reason ;-)

O sono ammessi molti costruttori come possibili stati validi. ( A meno che non ce ne fossero troppi, in tal caso prevarrà il modello di builder)

score 0 · Answer 2

Come vedo io hai le seguenti alternative:

Il metodo dovrebbe prendere gli argomenti necessari per creare l'immagine e restituire l'oggetto creato.
Il metodo dovrebbe essere void CreateImage(image) e semplicemente associare l'ID generato all'oggetto passato.

La seconda alternativa potrebbe non essere una buona progettazione al 100% poiché abbiamo dovuto creare un oggetto che si trova in uno stato incoerente finché non è stato chiamato il metodo create . Ma è un piccolo sacrificio che molti sembrano accettare rispetto all'alternativa (è comune quando si usano le librerie ORM).

because input simply does not use the id, so why would I pass it

Perché non è spesso che i metodi utilizzino tutte le proprietà di un oggetto. Se dovessimo passare solo le proprietà rilevanti di quanto faremmo nel caos del codice sorgente.

Un'altra cosa positiva con gli oggetti che passano invece delle loro proprietà è l'incapsulamento. Quando passiamo oggetti possiamo essere certi che rappresentano uno stato valido, dal momento che gli oggetti dovrebbero proteggere il loro stato (se seguiamo i principi OOP). Passando le loro proprietà come argomenti non si ottiene tale garanzia.