Pattern per il caricamento e la gestione delle risorse

Question

Pattern per il caricamento e la gestione delle risorse

#1 da (0 voti)
#2 da (0 voti)

2

Molte volte è necessario caricare risorse esterne nel programma, che si tratti di elementi grafici, campioni audio o stringhe di testo.

C'è un patten per gestire il caricamento e la gestione di tali risorse?

Ad esempio: dovrei avere una classe che carica tutti i dati e poi chiamarla ogni volta che ho bisogno dei dati? Come in:

GraphicsHandler.instance().loadAllData()
...//and then later:
draw(x,y, GraphicsHandler.instance().getData(WATER_IMAGE))
//or maybe
draw(x,y, GraphicsHandler.instance().WATER_IMAGE)

O dovrei assegnare ciascuna risorsa alla classe a cui appartiene? Come in (ad esempio, in un gioco):

Graphics g = GraphicsLoader.load(CHAR01);
Character c = new Character(..., g);
...
c.draw();

In generale, quale di questi due è la soluzione più solida?

GraphicsHandler.instance().getData(WATER_IMAGE)
//or
GraphicsHandler.instance().WATER_IMAGE //a constant reference

java design-patterns

posta Enoon 15.12.2012 - 11:31

fonte

2 risposte

0

Dipende dallo scopo della tua applicazione.

In alcuni giochi, è necessaria un'interfaccia utente altamente reattiva e il caricamento delle risorse durante il gioco potrebbe avere un impatto negativo. In secondo luogo, molti giochi funzionano con il 100% di utilizzo della CPU, esp. Tiratori 3D, in modo che tutti i dati che possono essere precaricati vengano anch'essi precaricati. Questo riduce i requisiti generali del sistema. Come si può vedere, ci sono motivi di prestazioni per il precaricamento delle risorse. Infine, le risorse sono spesso compresse all'interno di un archivio di grandi dimensioni per risparmiare spazio su disco. Ci vuole del tempo per decomprimere tutti i file per il livello corrente. Questa è l'ultima ragione per il precaricamento.

Il programma è un gioco? Ha bisogno di alcune di queste tecniche di ottimizzazione delle prestazioni? Altrimenti, il modello di progettazione più vicino per questo sarebbe Facade: link

Gfx ghost = (Gfx)ResourceLoader.load("/gfx/sprites/ghost");
Sound taunt = (Sound)ResourceLoader.load("/audio/boost/you_play_like_a_girl.voc");
Music levelMusic = (Music)ResourceLoader.load("/audio/music/level1.mp3");

Con la soluzione di cui sopra, può esserci una cache di risorse e si desidera registrare le risorse caricate più frequentemente. Successivamente, è possibile precaricare tali risorse implicitamente dopo l'avvio del programma perché sai che saranno necessarie. Non dovresti comunque precaricare tutto. Per ogni livello sono necessarie diverse risorse.

risposta data 16.12.2012 - 23:29

fonte

Leggi altre domande sui tag java design-patterns

Ripetibilità dei benchmark intensivi della CPU sull'hardware NUMA Come organizzare i test di integrazione e i dati di test per diversi ambienti quando si utilizza Maven Failsafe

score 0 · Accepted Answer

Non so che entrambe le opzioni saranno particolarmente solide. In entrambi i casi, si sta facendo affidamento su qualche tipo di implementazione singleton o statica per gestire l'ammontare delle variabili globali. Il modo in cui si accede alle variabili globali (direttamente o nascoste dietro una sorta di chiamata "getData ()" debolmente tipizzata) non avrà molta importanza per la manutenibilità di fronte a uno schema di variabili globali in generale. La tua applicazione sarà altamente cross-coupled e interdipendente in entrambi i modi.

Direi che un'opzione decente con un occhio alla flessibilità futura sarebbe quella di prendere il tuo concetto getData () e metterlo in un'interfaccia. Quindi iniettare un'istanza di tale interfaccia in classi che richiedono l'accesso ai dati (e cercare di limitare il numero il più possibile). In questo modo puoi prendere in giro o scambiare la cosa che fornisce quei dati. Il modo in cui lo hai ora, questo è impossibile - ogni client di tale singleton dipende dall'intero stato dell'applicazione che viene attivato per poter essere utilizzato, rendendo difficile, se non impossibile, il test e il disaccoppiamento. E questo stato di cose è il contrario di robusto.