Come eliminare la gerarchia parallela in scenari raw / renderizzati

0

Questa è una domanda basata sul design. Non sono libero di discutere il caso reale con cui ho a che fare, ma l'esempio che fornisco è rappresentativo del problema reale.

Sfondo

Diciamo che stiamo creando libri con finali diversi in base al modo in cui qualcuno progredisce attraverso il libro. Per semplicità, il nostro sistema genera una storia completa senza alcuna scelta per l'utente effettivo da scegliere, creando in effetti un libro normale. Dal punto di vista dell'utente finale, il libro non ha scelte.

Quando vogliamo generare un libro che l'utente possa leggere, un libro con le scelte viene "reso" dal sistema navigando attraverso le scelte nel libro e selezionando casualmente una delle scelte in ciascun ramo. Vogliamo memorizzare questa versione renderizzata affinché l'utente possa tornare in futuro, se lo desidera.

Il problema

La mia soluzione attuale è creare due gerarchie parallele, una per la versione originale e una per la versione renderizzata. Questo ci permette di mantenere la versione originale, quella che può essere resa di nuovo per un altro utente (o lo stesso utente se vuole vedere una versione diversa), e mantenere un record delle versioni generate per un utente specifico.

Sebbene questa soluzione sembri appropriata considerando le circostanze, mi chiedo se ci sia una soluzione migliore o un modello di progettazione che possa essere applicato qui. Le gerarchie parallele introducono un accoppiamento che sembra inevitabile, ma sarei interessato ad ascoltare altre prospettive.

Penso di aver coperto le basi del mio scenario, se hai bisogno di ulteriori dettagli, basta chiedere.

    
posta c1moore 11.08.2017 - 19:16
fonte

1 risposta

1

Dal suono di ciò, la nostra capacità di darti consigli è limitata dalla tua capacità di dirci quale sia la domanda. Possiamo usare la metafora del libro, ma se "il numero di scelte è molto alto", potrebbe essere necessario creare una soluzione adatta ai dati. In particolare, non usare mai le gerarchie OO all'interno di un kernel FFT. Adatta la soluzione al problema.

Come scritto, sembra che OO sia una soluzione valida. Fondamentalmente è necessario disporre di un "libro" per il tuo utente e di un "libro con opzioni" per archiviare tutte le possibilità, quindi dovrai memorizzare 2 serie di dati, non importa cosa.

Hai preso in considerazione un modello di peso mosca? La tua classe Book include le funzioni per esplorare le scelte che l'utente potrebbe eseguire, avere un ConcreteBook che contiene tutte le scelte e un SelectedBook che ha solo un percorso. Tutti i sottocomponenti del libro utilizzano il modello del peso mosca per gestire le scelte.

Supponiamo che tu abbia un Page . Ha una funzione getNextPages() per fare storie in stile "scegli il tuo-avventura". Tuttavia, lo modifichiamo leggermente. Invece abbiamo una funzione getNextPages(Book myBook) , che può essere passata come riferimento al tuo libro. Quindi, tutte le scelte di selezione possono essere gestite nella classe SelectedBook . Ogni sottocomponente come Page ha solo bisogno di sapere come ottenere abbastanza informazioni dal libro per fare il lavoro. In questo modo hai solo bisogno di un Page , un Bookmark uno Letter e un ChapterHeading . L'unica classe che deve essere duplicata è la Book stessa.

    
risposta data 11.08.2017 - 20:53
fonte

Leggi altre domande sui tag