2010-02-11 23 views
5

Non ho mai usato fabbriche prima per il semplice motivo, non capisco quando ne ho bisogno. Ho lavorato su un piccolo gioco nel mio tempo libero e ho deciso di implementare FMOD per il suono. Ho guardato un involucro progettato per OpenAL (configurazione audio diversa) e sembrava qualcosa di simile ...Comprendere le fabbriche e dovrei usarle?

SoundObject * SoundObjectManager * SoundObjectFactory *

La SoundObject era fondamentalmente l'istanza di ogni oggetto sonoro. SoundObjectManager gestisce solo tutti questi oggetti. Questo è abbastanza semplice e ha molto senso, ma non capisco cosa sta facendo la fabbrica o cosa viene usata. Ho letto su Factorys ma ancora non li capisco.

Qualsiasi aiuto sarebbe apprezzato!

risposta

2

Pensa a Factory come a un "costruttore virtuale". Permette di costruire oggetti con un comune tipo di tempo di compilazione ma diversi tipi di runtime. È possibile cambiare comportamento semplicemente dicendo alla Factory di creare un'istanza di un diverso tipo di runtime.

+0

Quindi per qualcosa di simile non è davvero necessario? Considerando che userò sempre istanze di SoundObject * e solo un singleton del manager. –

+0

Se non si hanno sottotipi SoundObject diversi, direi "no". – duffymo

+0

Non proprio, l'intento nell'impiegare lo schema è di isolare la creazione di oggetti dal loro utilizzo. Ciò consente di introdurre nuovi tipi derivati ​​senza alcuna modifica al codice che utilizza la classe base. Probabilmente hai sottotipi di SoundObject, ma semplicemente non lo sai, la Factory ti isola da quei dettagli di implementazione –

1

Le fabbriche vengono utilizzate quando è necessario parametrizzare l'implementazione. FMOD è multipiattaforma, ha bisogno di decidere quale implementazione concreta dare per la tua piattaforma. Questo è ciò che sta facendo la fabbrica. Esistono due modelli principali Abstract Factory Pattern e Factory Method Pattern.

1

Situazione ipotetica: sto scrivendo una libreria di suoni che voglio eseguire su più piattaforme. Cercherò di fare in modo che il maggior numero di codice possibile sia indipendente dalla piattaforma, ma sicuramente alcuni di essi dovranno cambiare per Windows rispetto a OSX rispetto a Linux.

Così scrivo tutte queste diverse implementazioni, ma non voglio che l'utente finale debba fare il il loro programma dipendente da Linux o Windows o qualsiasi altra cosa. Inoltre, non voglio mantenere 4 interfacce diverse per la mia API. (Nota: questi sono solo alcuni dei motivi per cui potresti creare una fabbrica - ci sono certamente altre situazioni).

Quindi definisco questa bella classe generica di base SoundObject che definisce tutti i metodi che il client può utilizzare. Quindi faccio il mio LinuxSoundObject, WindowsSoundObject e altri 5 derivano da SoundObject. Ma nasconderò tutte queste implementazioni concrete all'utente e fornirò solo un SoundObject. Invece, devi chiamare il mio SoundObjectFactory per afferrare quello che sembra essere un semplice vecchio SoundObject, ma in realtà ho scelto il tipo di runtime corretto per te e l'ho creato io stesso.

2 anni più tardi, un nuovo sistema operativo viene fuori e sposta Windows. Invece di obbligarti a riscrivere il tuo software, aggiorno semplicemente la mia libreria per supportare la nuova piattaforma e non vedi mai una modifica all'interfaccia.

Questo è tutto abbastanza artificioso, ma si spera che tu abbia l'idea.

Le fabbriche isolano i consumatori di un'interfaccia da quale tipo di runtime (vale a dire l'implementazione) viene effettivamente utilizzato.

+0

Questo ha perfettamente senso, si dovrebbe guardare nella scrittura di C++ per libri manichini lol. Per quanto riguarda il link che ho inserito nel commento sopra, non sono ancora esattamente sicuro di cosa stia facendo, ma sembra che usi la fabbrica per trasformarlo in un oggetto Movable, ma non lo capisco. Dal momento che questo è solo un progetto di apprendimento in cui andrò senza uno per ora, suppongo e saprò quando ne avrò bisogno per usarne uno in futuro. –

+0

Questo non è specifico per C++, è un modello di progettazione generale per tutti i linguaggi OO (e alcuni non OO) –

0

Le fabbriche possono essere utilizzate per implementare l'inversione del controllo e per separare il codice di istanziazione (le "nuove") dalla logica dei componenti. Ciò è utile quando si scrivono i test unitari poiché non si desidera che gli oggetti testati creino una serie di altri oggetti.

Problemi correlati