Come strutturare il codice di un gioco: Dependency Injection e Inversion of Control
Il concetto di Dependency Injection in realtà è molto semplice, ma ve lo introdurrò ugualmente. Quando si programma ad oggetti, si tende a scomporre un problema (nel nostro caso scomponiamo un gioco) in tanti piccoli sotto-problemi, questi sotto-problemi sono chiamati "classi".
Una classe da sola non fa proprio nulla, ha bisogno di conoscere un "pezzetto di mondo esterno". Questo pezzetto che va conosciuto è chiamato anche "dipendenza". (per fare "questo" devo conoscere "qualcos'altro", un po come i parametri delle funzioni, ma il concetto viene esteso.)
Programmare un gioco "bene" significa programmarlo in modo che sia facile da modificare e da correggere. Per fare questo bisogna ridurre al minimo le "dipendenze". In poche parole: va "iniettato" solo ciò che è strettamente necessario. Un modo veramente bello di raggiungere questo scopo è programmare attraverso le "interfacce". Ovviamente i primi giochi che si creano, sono un "blob", ovvero un ammasso unico di codice che funziona quasi "per miracolo", con l'esperienza si impara a strutturare il codice "meglio".
Il design by contract, significa definire una serie di operazioni minimali (interfaccia), con le quali poter interagire con una determinata classe. Questo significa che le "particolarità" di una classe vengono nascoste al mondo esterno. Di conseguenza il mondo esterno ha bisogno di meno sforzo per interagire con noi (noi non dobbiamo conoscere il mondo esterno e il mondo esterno non deve conoscere noi, anche se entrambi devono conoscere l'interfaccia).
Come molti di voi sapranno usare un interfaccia è un concetto molto potente, in quanto permette a 2 sottoproblemi, di cambiare, perchè intanto la parte di "comunicazione" tra questi due sottoproblemi non è cambiata. Questo è importantissimo perchè permette di creare "codice modulare" più facilmente. (attenzione non tutto il codice modulare è basato su interfacce)
Inversione del controllo, chiamato anche Hollywood principle (non chiamare noi, siamo noi a chiamarti) è il concetto fondamentale che sta alla base dei frameworks, ed è molto importante perchè crea "un infrastruttura" che allevia i compiti degli utenti.
Chi di voi usa il C++ sa quanto sia noioso gestire la memoria, vanno chiamati "new" / "delete", senza contare che anche qualora decideste di utilizzare gli smart pointers e' abbastanza noioso starli ad inizializzare, l'idea di base quindi è automatizzare la "iniezione di dipendenze" per fare questo si usa l'Inversion of Control: se la vostra classe ha bisogno di una determinata dipendenza, non vi servirà più iniettarla manualmente usando un "new", anzi, non dovrete più nemmeno preoccuparvi di chiamare "new".
Si può creare infatti un framework che chiami "new" al posto vostro. Io ne ho scritto uno che potete scaricare liberamente dai server di Google.code:
Grazie a questo framework potrete dimenticarvi di chiamare "new" ed eliminerete i memory leaks dalla vostra applicazione. Il trucco sta nel fatto che le dipendenze sono note "a priori". Non è quindi necessario creare codice apposta per crearle e nascondere questo codice dentro le varie classi (debuggarlo sarebbe poi difficile), è sufficiente dire a qualcuno di farlo per noi, e come se non bastasse, questo avviene "in chiara luce", vicinissimo al nostro "main", dandoci la possibilità di cambiare le cose senza quasi toccare il codice "importante" della nostra applicazione. Per i progetti di dimensioni medie, il vantaggio che da un IoC framework è notevole e ancora di più per i progretti più grandi.
Questo framework utilizza un sacco delle nuove features del C++11, non è possibile farne a meno. Sono così comode e permettono di scrivere codice così pulito che una volta iniziato ad usarle e averle capite non potrete più farne a meno:
Per chiarimenti potete commentare questo articolo.