Come strategia di base, eviterei quasi sempre di archiviare lo stesso pezzo di informazione in due diversi posti / classi di un modello di dati, che conduce troppo facilmente a codice non gestibile. Se inizi ad avere attributi come numberOfMonths
in due classi (come è stato suggerito in un'altra risposta), possono deviare gli uni dagli altri, potresti dover scrivere codice per impedirlo, devi preoccuparti di quale sia la versione "principale" di quell'attributo potrebbe dover duplicare la documentazione e così via.
Una soluzione che hai suggerito era "Un campo genitore in modo che possiamo attraversare il backup dell'oggetto per ottenere i dati" . Va bene quando nel tuo dominio aziendale ogni oggetto PaidByItem
è correlato in qualche modo a un Xyz
e a un Aaa
oggetto. Quindi ha senso esprimere quella relazione anche nel codice con un riferimento:
public class PaidByItem {
int feeAmount = 100;
Xyz xyz; // lets assume this is Java or C#, so a reference, no copy!
AAA aaa;
// ...
public double totalAmount (){
return feeAmount * xyz.numberOfMonths / aaa.daysPerYear;
}
}
I nomi non sensoriali come Xyz
o Aaa
, tuttavia, non ci dicono molto sul vero dominio. Ci possono essere molti motivi per cui non vuoi introdurre una dipendenza da Xyz
o Aaa
in PaidByItem
. Ad esempio, potrebbero portare a una dipendenza ciclica da evitare, oppure questo tipo di relazioni / riferimenti semplicemente non ha alcun senso dal punto di vista del dominio. In questi casi, spesso è preferibile utilizzare l'altro suggerimento "Una classe di calcolo separata per ottenere i dati, eseguire il calcolo e restituire un valore ". In alternativa, puoi cambiare il design in
public double totalAmount (int numberOfMonths, int daysPerYear){
return feeAmount * numberOfMonths / daysPerYear;
}
che significa che il chiamante di questo metodo ha la responsabilità di assicurarsi che le funzioni totalAmount
vengano chiamate con i parametri corretti dagli oggetti giusti. L'ultima opzione ha più senso quando non è richiesto che quei parametri come numberOfMonths
provengano da uno specifico oggetto di riferimento.
TLDR: evita l'archiviazione ridondante, scegli la soluzione che rappresenta il tuo dominio aziendale in modo più appropriato.