Tenere traccia di tutti gli oggetti di una classe

Question

Tenere traccia di tutti gli oggetti di una classe

#1 da (7 voti)
#2 da (3 voti)
#3 da (2 voti)
#4 da (2 voti)

7

Sono nuovo nella programmazione orientata agli oggetti e continuo a occuparmi di questo problema. (Sto programmando in Java) Sono stato un po 'riluttante a chiedere su questo, dal momento che sembra un problema di base, ma non riesco a trovare alcuna informazione su di esso, o domande su di esso qui, e nessuno dei i libri di testo che ho letto (su un livello abbastanza semplice ovviamente) hanno toccato questo problema:

Spesso ho bisogno di tenere traccia di tutti gli oggetti di una classe che sono stati creati, per scorrere attraverso di loro per vari scopi. Il modo in cui attualmente scrivo i programmi, molti oggetti sono referenziati da altri oggetti, il che significa che non ho array o collezione con cui fare riferimento a tutti loro.

Immagino che, visto che questo sembra una necessità così basilare in OOP, ci dovrebbe essere un modo abbastanza istituzionalizzato e semplice per fare questo? È prassi usuale tenere un elenco separato di tutti gli oggetti di una classe?

Ho pensato ad una matrice o collezione statica, a cui attraverso il suo costruttore, ogni nuovo oggetto creato sarebbe stato aggiunto. Questo tuttavia non funzionerebbe con sottoclassi, poiché i costruttori non sono ereditati?

Mi rendo conto che questa domanda potrebbe non avere una risposta facile; Spero solo che qualcuno possa illuminarmi un po 'su questo argomento. Mi sento come se mi mancasse un pezzo centrale di conoscenza qui.

object-oriented java collections class

posta zxz 11.06.2013 - 02:44

fonte

4 risposte

Leggi altre domande sui tag object-oriented java collections class

Come creare un'e-mail automatica in più lingue (multipart / alternative)? Scrum si presta a ambienti multi-progetto?

score 7 · Answer 1

Non so perché è necessario tenere un elenco di tutte le istanze di una classe.

Ciò causerebbe una perdita di memoria dal momento che quegli oggetti non saranno mai eliminati, poiché la lista continuerà a farvi riferimento dopo che nessun'altra classe fa.

Ma se vuoi davvero seguire questa strada:

Utilizza il modello di fabbrica. Una classe factory con metodi che instanzano la classe e restituiscono gli oggetti. In questo modo hai un punto centralizzato per controllare le istanze.
Utilizza il pattern Singleton per contenere un elenco o elenchi che contengono le istanze.
Fai la fabbrica metti ogni oggetto di un certo tipo in una lista dopo averli creati.

A proposito: i costruttori sono ereditati.

score 3 · Answer 2

Va notato che i riferimenti deboli possono essere utilizzato in combinazione con le altre soluzioni fornite per consentire al garbage collector di disporre di oggetti tracciati quando non vengono più referenziati altrove. Ciò elimina le perdite di memoria senza richiedere il codice altrove per smaltire manualmente gli oggetti, o comunque preoccuparsi che vengano monitorati. È possibile fornire un ReferenceQueue per ricevere notifiche sui riferimenti agli oggetti che sono stati liberati.

I thought about a static array or collection, to which through its constructor, every new object created would be added. This however would not work with subclasses, since constructors are not inherited?

I costruttori delle classi base sono invocati prima dei costruttori delle classi derivate. Ogni classe ha almeno un costruttore e i costruttori non possono essere sovrascritti.

score 2 · Answer 3

Quando si creano giochi, le persone talvolta desiderano una raccolta "autogestita" di ogni tipo di oggetto di gioco.

Un'implementazione è simile a questa:

public class Car {

    static ArrayList<Car> list = new ArrayList<Car>();

    public Car() {
        list.add(this);
    }

    void kill() {
        list.remove(this);
    }

    static public void updateAll()
    {
        for (int i = list.size() - 1; i >= 0; i--)
        {
                list.get(i).update();
        }
    }

    public void update()
    {
        //update logic
    }
}

In questo modo i metodi che manipolano la raccolta possono essere dichiarati statici mentre i metodi non statici manipolano un'istanza (updateAll vs. update).

Pur bene per gli molto semplici scenari, con una complessità anche moderata, di solito è meglio creare classi di manager separate.

score 2 · Answer 4

Prova a pensare al contesto. Quando crei un oggetto, lo fai in un certo contesto. Ad esempio, se il tuo gioco riguarda la fucilazione di alieni, la tua app creerà continuamente nuovi oggetti alieni. Verranno visualizzati in un campo chiamato Spazio (che potrebbe essere la classe che rappresenta l'interfaccia utente principale).

È perfettamente naturale che Space abbia una proprietà denominata currentAliens, che sarebbe un array, a cui aggiungere ogni nuovo alieno creato. Se vuoi consentire al tuo utente di distruggere il tessuto dello spaziotempo e distruggere tutti gli alieni in una volta, eseguirai l'iterazione attraverso quella raccolta e distruggi ogni oggetto.

Se vuoi avere accesso a questa raccolta di alieni da altre parti della tua app (ad esempio, da una pagina Impostazioni, dove potresti voler consentire agli utenti di eliminare alcuni tipi di alieni in un colpo solo), il tuo Il contesto delle impostazioni dovrebbe avere accesso all'oggetto Spazio.