"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à?