Riduzione dei cicli di dipendenza e riduzione dell'accoppiamento

Naviga le tue risposte
5

Sto cercando di imparare come produrre codice orientato agli oggetti di qualità e ho studiato concetti come SOLID. Attualmente sto lavorando a un sistema di processori entità-componente per un piccolo motore di gioco.

Attualmente, l'ho implementato come tale:

  • C'è un ScreenStack che contiene una pila di Screen s
  • Ogni Screen ha EntityManager e ProcessManager .
  • Il ProcessManager aggiorna tutto Process es dati entità da EntityManager .
  • Un Process gestisce tutte le logiche di gioco, quindi deve essere in grado di usare ScreenStack per possibilmente schermate push e pop. Può anche creare, rimuovere e modificare entità, quindi ha bisogno del EntityManager da Screen . Fondamentalmente un Process ha bisogno di sapere tutto sul gioco poiché ne influenza moltissimo, ma sembra sbagliato.

Come faccio a implementarlo meglio? Sembra che tutto abbia una chiara gerarchia delle dipendenze fino a quando non arrivi a un processo, dove viene espulso dalla finestra.

Sembra anche che ci sia un accoppiamento stretto quando vorrei spingere un nuovo schermo. Ad esempio, ho un processo in una schermata MainMenu che controlla la scelta del menu. Se viene cliccato "Nuovo gioco", ho bisogno di premere un nuovo schermo, che viene creato in quel momento. Ho letto che non dovrei lanciare in modo casuale new che sembra stia facendo.

    
posta Shane 03.09.2014 - 23:36
fonte

3 risposte

2

Suggerirei di esaminare il principio " Tell Do not Ask ". Martin Fowler offre una buona introduzione qui

L'implementazione comune di solito si basa su messaggi / notifiche tra le classi. Nota, TDA è un " pure OOP " per cui sono stati progettati linguaggi orientati agli oggetti. A differenza della più comune modalità mista di codice funzionale OO +.

Un altro consiglio è di lavorare su separazione delle query dagli aggiornamenti (non consentire il codice negli stessi metodi o persino classi per richiedere dati e agire su di esso) - che rimuove molta complessità accidentale e grande migliora SRP.

    
risposta data 21.11.2014 - 21:52
fonte
0

Un processo non ha bisogno di sapere tutto sul gioco, ma potrebbe essere necessario sapere cosa fa il gioco. Questa è la differenza fondamentale tra le classi e le interfacce . (Parte della "D" in solido.)

Immagina tutti i tuoi oggetti come separati e del tutto estranei. Quindi, immagina una singola connessione da ciascuno di questi a un servizio che fornisce istanze di interfaccia. Ogni collegamento tra le classi può essere rotto e sostituito con un insieme di comportamenti (chiamati un'interfaccia). Chiama qualcosa come GetInstance (...) per ottenere un'interfaccia esistente o crearne una nuova. L'oggetto consumatore non si preoccupa di quale, dove o quando l'istanza è stata creata, ma sa come usarlo. (Se hai esaminato l'iniezione di dipendenza, potrebbe iniziare a sembrare familiare.)

Torna alla realtà ora. Mentre separare le dipendenze degli oggetti usando Interfacce è un'idea generalmente buona, non è necessario rielaborare tutto ciò che già possiedi. Basta refactoring ciò che è difficile o non funziona correttamente, e continua ad andare avanti.

    
risposta data 04.09.2014 - 03:33
fonte
0

Suppongo che tu stia cercando di rendere il motore di gioco basato sui processi. Cioè Il processo deciderà cosa dovrebbe accadere nel gioco e cambierà lo stato del gioco. Mi piace l'idea, ma non sono mai stata in grado di applicarla al mio gioco (ne ho terminata solo una).

Il nocciolo del problema era che il mio gioco non era guidato da processi. Gli input provenivano dal frontend (Screen o ScreenStack nel tuo caso) ovviamente, quindi ho dovuto sacrificare l'architettura process-driven per uno stratificato: 'frontend' usa 'backend'. Backend contiene la maggior parte della logica di gioco (processi ed entità nel tuo caso), ma il frontend è il driver. Il backend non può spingere gli schermi. Il backend non sa nulla di frontend. Il backend è solo uno schiavo del frontend. Questo è quello che ho finito. Forse il tuo gioco è simile.

    
risposta data 02.10.2014 - 21:43
fonte

Leggi altre domande sui tag

Schema / Motivo di progettazione per consentire a una determinata classe esterna di impostare le proprietà Perché il metodo Jacobi è un buon algoritmo candidato da implementare su una GPU?