Configurazione dinamica del software

Question

Configurazione dinamica del software

#1 da (1 voti)

2

Questo post ci insegna a separare costruzione di un oggetto grafico dalla logica dell'applicazione in due classi diverse e l'obiettivo finale è di avere: classi con classi OR logiche con operatori "nuovi". Sembra davvero bello, poiché proveniente da questo post puoi capire che se hai iniziato a fare DI dovresti farlo completamente e non parzialmente per non infrangere la Legge di Demetra. Quindi dovresti usare le fabbriche, dove tutti gli oggetti sono creati e quindi delegati ad altri per riferimento per creare il grafico dell'oggetto.

Ma cosa succede se ho bisogno di modificare il runtime della struttura del grafico? Cosa succede se alcuni oggetti nella gerarchia inferiore stanno prendendo questa decisione critica? (Ad esempio, ho 2 scene di gioco, e voglio passare dalla scena "InGame" alla scena "MainMenu" se il giocatore colpisce qualche oggetto e quella collisione viene rilevata sotto nella gerarchia.)

Quando stavo leggendo questo speravo che spiegherà la soluzione. Ma in realtà no. Quindi, per favore dimmi come creare nuovi oggetti che cambiano la configurazione del software e hanno bisogno di molti Iniettabili per cambiarli quando sono nella gerarchia inferiore.

Un modo per farlo è passare la Factory, che crea la nuova configurazione, giù per la gerarchia, ma questo rompe il minimo di Demeter.

Un altro modo è usare il pattern Observer e inviare un evento alla Factory, in modo che possa cambiare la struttura del grafo degli oggetti, dato che ha tutti gli iniettabili e può facilmente creare oggetti. Dopotutto, questo è il lavoro che fa. Ma non sono sicuro, questa è la cosa giusta da fare.

Condividi la tua esperienza.

object-oriented-design

posta Narek 18.10.2015 - 07:03

fonte

1 risposta

Leggi altre domande sui tag object-oriented-design

Come incorniciare il concetto dietro CMake? Flusso di lavoro per catene di richieste di pull dipendenti a progetti che dipendono da altri progetti

score 1 · Answer 1

Credo che la preoccupazione principale qui sia la durata necessaria delle tue dipendenze, che è strettamente legata al grado di astrazione rispetto alla specializzazione al loro interno.

Se un oggetto più in basso nella gerarchia ha bisogno di iniziare un cambiamento nella scena del gioco, mi aspetterei che la dipendenza che manipolerebbe sia qualcosa come GameSceneManager con un metodo .SetCurrentScene (), in quanto opporsi alla dipendenza essendo un'istanza di un Tipo GameScene che deve essere sostituito con un nuovo oggetto.

Può esistere una variabile di istanza che denota l'attuale GameScene, ma dovrebbe essere contenuta nell'oggetto GameSceneManager. La factory per la creazione di tali oggetti sarebbe una dipendenza dell'oggetto GameSceneManager.

Con questa struttura, il tempo di vita dell'oggetto GameSceneManager è lo stesso dell'oggetto client che dipende da esso, il grafico dell'oggetto non ha bisogno di cambiare quando la scena viene aggiornata. All'interno dell'oggetto GameSceneManager la variabile di istanza contenente l'oggetto GameScene corrente viene aggiornata con un nuovo oggetto, ma da una fabbrica di cui il client conosce già (ha un riferimento).

In questo modo viene mantenuta la legge di Demeter, tutte le dipendenze possono essere iniettate durante l'inizializzazione del grafico dell'oggetto e non devono mai essere cambiate radicalmente.