Oggetti aggregati

Question

Se hai una classe A che è un aggregato di classe B e C, è meglio per A

• per memorizzare gli ID per B e C
• per caricare e archiviare l'intero oggetto per B e C (modifica, archivia facendo riferimento all'oggetto B / C, ovvero oggetti di istanza B e C invece di memorizzare ID per B e C.
• memorizza gli ID e fornisce metodi per estrarre i metodi B e C

Suppongo che ciò vari a seconda dei requisiti di prestazione e di altri requisiti, ma sto solo cercando linee guida o pensieri generali.

Answer 1

In un tipico programma in esecuzione in memoria, gli oggetti saranno quasi sempre memorizzati come riferimento come puntatori, quindi stai memorizzando gli ID per B e C, è solo che non gestisci i dettagli da solo, la lingua li nasconde da te.

Caricamento e memorizzazione dell'intero oggetto " è un concetto discutibile. So che stai cercando di essere indipendente dalla lingua, ma una delle prime cose che mi ha davvero aiutato " Ottieni " OO è che quasi ogni oggetto dovrebbe avere un proprio ciclo di vita.

Se hai un oggetto A che contiene " Contiene " oggetto B e si passa un riferimento all'oggetto B all'oggetto C, quindi l'oggetto A deve sapere qualcosa sull'oggetto C, questo NON è del tutto OK. Liberare il ciclo di vita dell'oggetto B in modo che l'oggetto A non sappia nulla dell'oggetto C è uno dei concetti chiave che fa funzionare OO.

Quindi, se è quello che intendevi con la memorizzazione dell'intero oggetto, allora no, non farlo mai.

E questo vale anche per i database e altri tipi di archiviazione. Anche se un oggetto è responsabile della distruzione di un altro, raramente dovrebbe contenere i dati degli altri oggetti.

E (anche se penso che intendessi dire "pull oggetti B e C", non "metodi"), anche il concetto di poter passare un oggetto da un altro è molto utile e generalmente non c'è nulla di sbagliato in con un avvertimento:

Ricorda che un oggetto non ha alcun controllo su ciò che accade al di fuori di se stesso. Potrebbe essere passato in giro, metodi chiamati in un ordine semi-casuale, ecc. Pertanto è utile mantenere l'oggetto il più sicuro possibile. Se qualcosa viene chiamato nell'ordine sbagliato, o viene passata una variabile non valida, o scopri che in qualche modo hai inserito uno stato non valido, Fail early and Fail LOUD in modo che il programmatore che ha commesso un errore lo abbia chiamato.

Devi anche rendere il più difficile possibile entrare in uno stato illegale - questo significa mantenere l'oggetto piccolo e semplice, rendere le variabili definitive ogni volta che è possibile e cercare di non avere troppi punti in cui l'ordine dei parametri è importante.

Answer 2

Tendo a caricare e archiviare gli oggetti interi (e i loro oggetti secondari) come approccio predefinito.

A volte questo può causare lunghi tempi di caricamento, un ingombro di memoria elevato o entrambi. Quindi dovrai determinare se tutti gli oggetti caricati sono effettivamente utilizzati o se molti sono stati creati e non sono mai stati utilizzati.

Se vengono utilizzati tutti gli oggetti, sarà necessario un approccio più creativo per caricare un sottoinsieme, elaborarli, eliminarli e quindi caricare il sottoinsieme successivo per adattare tutto alla memoria o semplicemente acquistare più memoria e renderla disponibile per la tua app.

Se molti degli oggetti non vengono utilizzati, l'approccio migliore è caricare pigramente gli oggetti secondari quando sono necessari.

Answer 3

Questo dipende dalla situazione. Se gli oggetti rimangono in memoria, è più OO (e più facile) avere A contenere B e C. Ho scoperto che se gli oggetti devono essere persistenti, tuttavia, rende le cose più facili ed efficienti per A archiviare gli ID per B e C. (In questo modo se hai bisogno di dati direttamente in A ma non in B e C, non dovrai estrarre B e C dal database, dal file, ecc.)

Answer 4

Dipende,

Se B e C sono pesanti e costosi da caricare e costruire, potrebbe essere utile rimandare il loro caricamento fino a quando non si è sicuri che siano necessari (Lazy Initialize).

Se sono semplici e leggeri, forse vuoi solo costruirli ogni volta, ottieni gli ID.