Ho un po% di context
allora posso fare:
con context.getError(Object): ErrorHolder
holder.addError(error)
o
context.setError(Object, error)
setError avrà probabilmente questa implementazione:
context.getError(Object).addError(error)
quale approccio dovrei scegliere e perché?
Sicuramente andrei con il secondo metodo. Perché?
Beh, sembra essere la risposta più semplice. Nel primo caso richiederà due chiamate ogni volta che è necessario aggiungere o ricevere un errore dal proprio contesto.
C'è un'altra alternativa, purché tu stia fornendo le tue classi Object e non siano generate da una lib di terze parti.
È possibile aggiungere una proprietà ErrorCollection alla classe base degli oggetti dati che mantiene gli errori. In questo modo quando il tuo oggetto si muove attorno agli errori sono collegati ad esso.
In questo modo avrai
object.addError()
object.getError(index)
Questo è più pulito perché non stai mantenendo oggetti e una relazione di oggetti con i loro errori.
Non è questo il caso in cui violerebbe la Legge di Demeter ?
Il secondo, purché tu usi un nome come context.addError(object, error) se puoi effettivamente avere diversi errori su un oggetto, nasconde ErrorHandler ai client del contesto. ErrorHandler è un dettaglio di implementazione, oppure i client di 'context' lo usano anche?
Sono un fan di mantenere le cose semplici. Ciò migliora la leggibilità e l'usabilità di un'API. Non penso che ci sia una risposta definitiva, ma opterei per il secondo approccio, anche se chiamerei il metodo context.addError(object, error) , perché questo implica che potrebbero essere più di un errore, che è il caso, quando guardo alla tua possibile implementazione.
Anche l'approccio getError (oggetto) non ha una buona nomenclatura, penso. Se scegli il primo approccio, considera la denominazione del metodo getErrorHolder(object).getError() .
EDIT: se continuo a sbagliare, è un segnale per i nomi ambigui. Utilizza add per l'aggiunta a una raccolta e set per le singole istanze.
Leggi altre domande sui tag java design-patterns