Seleziona il modello di progettazione - stage dell'utente

"Sto cercando di fare X, quale modello di progettazione dovrei usare?" di solito è la domanda sbagliata da fare.

Un modello di progettazione è una soluzione comprovata a un problema ricorrente, ma il suo valore come modello sta in gran parte nel suo nome: una volta risolti requisiti simili in modi simili più volte, è possibile ricorda facilmente la combinazione di classi e relazioni che hanno svolto il lavoro e puoi comunicare più facilmente la decisione ad altri professionisti che conoscono anche il nome e il modello.

Ma quando non sai cosa fare per una serie di requisiti, semplicemente ti viene detto che il nome di un modello non farà quasi nulla per te. Dovrai seguire i dettagli della situazione, capire le pressioni coinvolte e perché una decisione è preferibile a un'altra, al fine di eliminare qualsiasi beneficio dall'apprendimento del modello. È quasi sempre meglio tentare la propria soluzione per comprendere i compromessi coinvolti e quindi confrontare il proprio codice con il codice di esempio fornito nella documentazione del modello. Quindi, avrai reinventato un pattern: congratulazioni, hai aggiunto uno strumento utile al tuo kit di strumenti. Oppure potresti improvvisamente "vedere la luce" e capire perché quest'altra disposizione di classi e metodi funziona meglio - congratulazioni, hai acquisito un nuovo strumento e hai trovato una soluzione per il tuo compito. (Oppure potresti scoprire che la tua soluzione funziona davvero meglio.) Doppi complimenti! Hai avuto successo meglio di altri, e forse potresti finalmente estenderlo a un nuovo modello.)

In ogni caso, di solito fai meglio scrivendo il codice per il tuo problema e quindi confrontandolo con soluzioni di esempio che scegliendo un modello di design e ricreandolo per il tuo caso d'uso semplicemente perché è un buon modello noto. Non sai se un pattern è adatto alla tua situazione fino a quando non hai provato e comprendi cosa rende complicato. Vedendo immediatamente "Ah, ho bisogno di costruire un Bridge per questo" funziona solo quando conosci già il tuo problema e il modello di progettazione dall'esperienza.

Finora, non hai descritto nulla che richiederebbe un complicato sistema di classi di cooperazione. Gli utenti possono risolvere compiti e avanzare attraverso fasi e possono acquistare benefici. Non sembra qualcosa di più complicato di un'entità con tre attributi, o forse n: m relazioni per compiti e benefici. Che cosa ti sta dando problemi in modo che pensi che l'implementazione diretta non funzionerà?

In questo momento non puoi davvero decidere uno schema di design specifico. La tua descrizione è troppo alta.

Per essere in grado di decidere su un modello di progettazione, devi prima costruire un modello doman che mostri le entità principali nel tuo sistema e le cardinalità associate.

Dalla lettura della tua descrizione ci sono tre entità principali che saltano fuori:

Utente, Attività, Stage

E in misura minore, che potrebbe richiedere alcuni chiarimenti:

Punto, vantaggio

Una volta che hai un modello di dominio (che è fondamentalmente un modello di classe UML), puoi iniziare ad analizzare le interazioni e, se ti va, crea dei diagrammi di sequenza.

Solo dopo questa analisi puoi veramente iniziare a vedere se hai bisogno o meno di un modello di strategia, di un modello di comando, di un modello di ponte ecc. ecc.

Potresti essere interessato a Pattern di progettazione dello stato , che consente di incapsulare il comportamento variabile di un oggetto in base al suo stato interno.

Se stai utilizzando il pattern di architettura MVC per creare l'applicazione web, potresti pensare di utilizzarla nel controller dell'applicazione web.