I giochi al dettaglio usano "inversione di controllo" e "iniezione di dipendenza"?

Molti degli sviluppatori di software più diligenti che conosco si stanno muovendo verso l' inversione del controllo e l' iniezione di dipendenza per gestire i riferimenti agli oggetti. Dal punto di vista dei giochi Flash non conosco tutti i dettagli degli studi AAA, quindi: sono usati nel mondo dei giochi al dettaglio?

Lo chiami "diligente sviluppo di software", io lo chiamo "doloroso overengineering". Ciò non vuol dire che l'inversione del controllo sia negativa - in effetti, la definizione di base è buona - ma la proliferazione di interi quadri e metodi di lavoro per raggiungere tutto ciò è a dir poco folle, specialmente combinata con il modo in cui le persone distruggono interfacce perfettamente buone e pulite per poter iniettare componenti intercambiabili che il 99% delle volte non scambierete mai. È il genere di cose che potrebbe provenire solo dall'ambiente aziendale Java e sono contento che non abbia un punto d'appoggio altrove.

Spesso l'argomento è che anche se non si scambiano componenti, si desidera poterli testare in isolamento con oggetti similari e simili. Tuttavia, temo che non comprerò mai l'argomento secondo cui vale la pena gonfiare e complicare un'interfaccia per poterlo testare meglio. I test dimostrano solo una cosa: che i test funzionano. Le interfacce pulite e minimali d'altro canto fanno molto per dimostrare che il tuo codice funziona.

Quindi, la risposta breve: sì, ma non nel modo in cui stai pensando. A volte, quando hai bisogno di un comportamento intercambiabile, passerai un oggetto a un costruttore che detta parte del comportamento del nuovo oggetto. Questo è tutto.

Pattern di strategia , composizione , iniezione di dipendenza , sono tutti strettamente correlati.

Poiché il modello di strategia è una forma di iniezione di dipendenza, se dai un'occhiata a motori come Unity, ad esempio, sono completamente basati su questo principio. Il loro uso di componenti (modello di strategia) è profondamente incorporato in tutto il loro motore.

Uno dei principali vantaggi oltre al riutilizzo dei componenti è quello di evitare le temute gerarchie di classi profonde.

Ecco un articolo di Mick West che parla di come ha introdotto questo tipo di sistema nella serie di giochi Tony Hawk di Neversoft.

Fai evolvere la tua gerarchia

Fino a anni piuttosto recenti, i programmatori di giochi hanno costantemente utilizzato una gerarchia di classe profonda per rappresentare le entità di gioco. La marea sta iniziando a spostarsi da questo uso di gerarchie profonde a una varietà di metodi che compongono un oggetto entità di gioco come aggregazione di componenti ...

Sembra esserci molta confusione sul modello di Inversion of Control (IoC). Un certo numero di persone lo ha identificato con il modello di strategia o un modello di componente, ma questi confronti non catturano realmente ciò che è IoC. IoC riguarda davvero come si ottiene una dipendenza. Lasciate che vi faccia un esempio:

class Game {
    void Load() {
        this.Sprite.Load(); // loads resource for drawing later
    }
}

class Sprite {
    void Load() {
        FileReader reader = new FileReader("path/to/resource.gif");
        // load image from file
    }
}

In quanto sopra è chiaro che Sprite.Loadha una dipendenza da a FileReader. Quando si desidera testare il metodo è necessario quanto segue:

1. Un file system in atto
2. Un file di prova da caricare dal file system
3. Capacità di innescare errori comuni del file system

I primi due sono ovvi, ma se vuoi assicurarti che la tua gestione degli errori funzioni come previsto, hai davvero bisogno anche del n. 3. In entrambi i casi hai potenzialmente rallentato un po 'i tuoi test in quanto ora devono andare su disco e probabilmente hai reso il tuo ambiente di test più complicato.

L'obiettivo di IoC è di disaccoppiare l'uso del comportamento dalla sua costruzione. Nota come questo differisce dal modello di strategia. Con il modello di strategia l'obiettivo è incapsulare un pezzo riutilizzabile di comportamento in modo da poterlo estendere facilmente in futuro; non ha nulla da dire su come sono costruite le strategie.

Se dovessimo riscrivere il Sprite.Loadmetodo sopra, probabilmente finiremmo con:

class Sprite {
    void Load(IReader reader) {
        // load image through reader
    }
}

Ora, abbiamo disaccoppiato la costruzione del lettore dal suo uso. Pertanto, è possibile scambiare un lettore di test durante i test. Ciò significa che l'ambiente di test non ha più bisogno di un file system, file di test e può simulare facilmente eventi di errore.

Nota che ho fatto due cose nella mia riscrittura. Ho creato un'interfaccia IReaderche ha incapsulato alcuni comportamenti, ovvero implementato il modello di strategia. Inoltre, ho spostato la responsabilità della creazione del lettore giusto in un'altra classe.

Forse non abbiamo bisogno di un nuovo nome di modello per descrivere quanto sopra. Mi colpisce come un mix di modelli di strategia e fabbrica (per contenitori IoC). Detto questo, non sono sicuro dei motivi per cui le persone si oppongono a questo modello in quanto è chiaro che risolve un problema reale e, certamente, non è ovvio per me cosa abbia a che fare con Java.

Direi che è uno strumento tra i tanti e che viene usato occasionalmente. Come diceva tenpn, qualsiasi metodo che introduce vtables (e in genere qualsiasi ulteriore indiretta) può avere una penalità di prestazione, ma questo è qualcosa di cui dovremmo preoccuparci solo per il codice di basso livello. Per un codice strutturale di alto livello che non è realmente un problema e l'IoC può avere vantaggi positivi. Tutto ciò per ridurre le dipendenze tra le classi e rendere il codice più flessibile.

Devo essere d'accordo con Kylotan su questo. "Dependency injection" è una brutta soluzione Java a un brutto difetto concettuale Java, e l'unica ragione per cui qualcuno la sta guardando in altre lingue è perché Java sta diventando la prima lingua per molte persone, quando in realtà non dovrebbe.

L'inversione del controllo, d'altra parte, è un'idea utile che esiste da molto tempo ed è molto utile se fatta bene. (Non nel modo Java / Dependency Injection.) In effetti, probabilmente lo fai sempre se lavori in un linguaggio di programmazione sano. Quando ho letto per la prima volta l'intera faccenda del "CIO" di cui tutti parlavano, ero completamente deluso. L'inversione del controllo non è altro che il passaggio di un puntatore a funzione (o puntatore a metodo) a una routine o a un oggetto al fine di aiutare a personalizzarne il comportamento.

Questa è un'idea che esiste dagli anni '50. E 'nella libreria standard C (qsort viene in mente) ed è tutto il luogo in Delphi e .NET (gestori di eventi / delegati). Consente al vecchio codice di chiamare un nuovo codice senza dover ricompilare il vecchio codice e viene utilizzato continuamente nei motori di gioco.

Non nella mia esperienza. È un peccato, dato che il codice dei giochi deve essere molto adattabile e questi approcci sarebbero sicuramente di aiuto.

Tuttavia, va detto che entrambi i metodi potrebbero, in C ++, introdurre tabelle virtuali dove prima non esistevano, portando con sé un successo prestazionale adeguato.

Non sono uno sviluppatore di giochi professionale e ho provato a implementare l'IoC in C ++ solo una volta, quindi è solo una speculazione.

Tuttavia, sospetto che gli sviluppatori di giochi sarebbero sospettosi di IoC perché significa:

1 / progettazione di molte interfacce e molte piccole classi

2 / avendo praticamente tutte le chiamate di funzione associate di recente

Ora, potrebbe essere una coincidenza, ma entrambi tendono ad essere un po 'più complicati e / o problematici per le prestazioni in C ++ (che è ampiamente usato nel gioco, non è vero?) Rispetto a Java, dove l'IoC si è diffuso (probabilmente perché era relativamente facile da fare, aiutare le persone a progettare gerarchie di oggetti più sani e poiché alcuni credevano che potesse trasformare la scrittura di un'applicazione in Java in scrittura di un'applicazione in XML, ma questo è un altro dibattito: P)

Sono interessato ai commenti se ciò non ha alcun senso;)