Passaggio dei dati tra centinaia di oggetti in java [chiuso]

Hai due opzioni:

1. Ogni agente conosce ogni altro agente e interroga gli agenti in base alle esigenze.
2. Ogni agente pubblica le sue modifiche di stato e altri agenti ascoltano le modifiche a cui tengono.

Il secondo approccio ha diversi vantaggi rispetto al primo, il più importante è che i cambiamenti avvengono solo quando necessario. Ad esempio, se solo 2 agricoltori commerciano terreni, la città non ha bisogno di interrogare gli altri 97 agricoltori.

Ci sono molti modi per implementarlo. Vorrei che non inserisse un database nel mix, ma userei invece un bus di eventi in memoria con pubblicazioni e sottoscrittori. Ci sono sistemi pronti per farlo, oppure potresti farcela da solo.

Come indicato nelle altre risposte, dipende dalle circostanze uniche (necessarie per eseguire le simulazioni) se utilizzare un database reale o un reale geografico sistema (GIS).

Indipendentemente dalla scelta degli strumenti, una cosa è certa: le vostre simulazioni coinvolgeranno una logica applicativa che è superficialmente simile a ciò che viene fatto dai database e dai sistemi GIS. Vale a dire:

• Query su un gran numero di oggetti - alcuni dei quali potrebbero trovarsi al di fuori della gerarchia degli oggetti.
• Calcoli ad es. somme, medie, minimi e massimi o altre operazioni statistiche / matematiche / geometriche su oggetti entro una certa estensione spaziale.
  • Vedi: Query spaziale e Ricerca vicino più vicino .

Riconosci che dovrai imparare nuovi concetti indipendentemente da cosa.

• L'utilizzo di strumenti esistenti (database e sistemi GIS) non ti evita di doverti imparare sulle query relazionali e spaziali.
• Scrivere il tuo codice non ti evita di dover conoscere le query relazionali e spaziali (*).

_{(*) ripetuto per enfasi.}

Tuttavia, utilizzando gli strumenti esistenti,

• Potresti risparmiare tempo implementando algoritmi per farlo.
• In cambio, passerai più tempo a imparare come funzionano quegli strumenti e a formulare i tuoi requisiti di simulazione in query con questi strumenti.

D'altra parte, la preoccupazione espressa nella tua domanda è troppo lontana dai tuoi bisogni immediati. Vale a dire:

• Dovrei privilegiare un approccio centralizzato (database) o un approccio decentralizzato (peer-to-peer o orientato agli oggetti) durante la modellazione di queste operazioni?
• Quale sarebbe la performance di ciascun approccio?
  • (vedi sotto).
• Come faccio a partizionare il sistema per la scalabilità?

Puoi sempre rivisitare le decisioni architettoniche il prossimo mese ; tuttavia, devi capire come soddisfare le esigenze della tua applicazione di simulazione questa settimana .

Quale sarebbe la performance di ciascun approccio?

In pratica, non sapresti fino a quando non applichi entrambi gli approcci, li ottimizzi e poi confronti il loro rendimento.

In teoria, dobbiamo sapere esattamente quali tipi di algoritmi (query) vengono eseguiti. Ad esempio:

• Le query possono essere risolte "mantenendo un conteggio (somma) aggiornato"
• Le query possono essere risolte da una ricerca di una manciata di elementi
• Query che riguardano la ricerca spaziale 2D
• Query che richiedono la valutazione di un'equazione matematica per ogni coppia di oggetti. (Questo sarà lento.)

Se si forniscono solo "esempi", l'utilità del consiglio dipenderà dalla qualità degli esempi che riflettono le esigenze dell'applicazione.

Ottieni prima il disegno dei dati. Capire quali dati sono necessari per ogni entità e come le entità si riferiscono dovrebbe semplificare la progettazione.

Potresti scoprire di avere molte entità che possono essere modellate come sottotipi. Diversi sottotipi possono avere un comportamento diverso, ma dovrebbero contenere lo stesso stato (dati). Comprendere i comportamenti comuni e specifici di agenti simili ti aiuterà a progettare la tua gerarchia di classi.

Probabilmente vorrai un database per la persistenza, ma mantieni il comportamento nell'applicazione. Mi aspetterei che la maggior parte dei dati sia a riposo (persistente nel database) per la maggior parte del tempo. I database possono essere abbastanza efficienti nel rispondere a domande come quanti ettari hanno gli agricoltori in questa città.

Se per agente si intende oggetti, allora si sta osservando un insieme piuttosto piccolo di dati. Potrebbe essere possibile conservare i dati in un database in memoria. Anche se non lo fai, i dati potrebbero adattarsi bene al database e / o alla memoria del sistema operativo.

MODIFICA: il contenitore deve essere collegato in pool al database in modo che non sia necessario alcun agente che si connetta a mysql. Dovrebbero chiedere l'oggetto del modello (proxy del database) per i dati e quelli possono eseguire una query del database. I database ben progettati sono molto efficaci nella raccolta di dati sulle entità correlate (agenti).

A meno che non si stiano eseguendo simulazioni di dati a lungo termine, è improbabile che i cambiamenti si verifichino abbastanza spesso da far funzionare molto bene una struttura di tipo osservatore / mediatore. Questo schema è più appropriato quando i dati cambiano più volte al minuto, non più volte l'anno. Anche con centinaia di agricoltori, mi aspetterei che i cambiamenti siano minuti tra la stagione del raccolto e i giorni tra il resto dell'anno.

Se stai facendo tutto in memoria rischi di perdere tutti i dati ogni volta che l'applicazione si interrompe. Per un periodo di anni, questa sarà una certezza. Essere in grado di aggiornare e riavviare l'applicazione sembra essere essenziale per la tua evoluzione del design.