Design pattern per ruolo utente free / premium

Chiarisci i tuoi requisiti

Quale dei seguenti hai intenzione di implementare?

• premium / gratuito utenti (come suggerito nel titolo): hai un'app con un design basato su ruolo . Un'istanza dell'app potrebbe avere diversi utenti. La stessa app offre un comportamento diverso a utenti diversi (in base al loro ruolo attivo).
• premium / gratuito app (hai scritto " abbiamo un'app con versione gratuita e versione premium "): un'istanza dell'app offre lo stesso comportamento per tutti i suoi utenti in un dato momento. Il comportamento prematrimoniale può essere temporaneamente attivato ma è lo stesso per tutti gli utenti.
• premimum / free servizio (hai scritto " utente premium non può avere un metodo per pagare diventare un utente premium "): esponi un'API o fornisci una libreria che blocca l'accesso all'API, in modo che tu sia davvero preoccupato dell'interfaccia interna.

Come implementare

Lo schema di stato come hai già scoperto sembra la risposta più appropriata a tutti i casi. A seconda delle tue esigenze, puoi utilizzare uno stato utente o uno stato dell'app.

Se offri un wrapper di libreria a un servizio, potrebbe essere importante offrire solo metodi pertinenti per lo stato. Ma questo rende la vita difficile per il tuo grimorio: prima deve interrogare lo stato, e poi deve sapere quale stato consente quale metodo. È terribile: finirai per avere molte dipendenze indesiderate nel codice client. Quindi offrirei la stessa interfaccia per tutti gli stati, ma aggiungere alcuni metodi per sapere se alcune funzionalità sono disponibili o meno che potrebbero essere chiamate prima di richiamare il metodo.

Se offri un'interfaccia utente e non un'API, devi agire correttamente sulla richiesta dell'utente. Quindi, se una funzione non è più disponibile, disattivarla nei menu o non fornire il pulsante o la gestione degli eventi per essa. L'utilizzo di un'interfaccia dipendente dallo stato renderebbe difficile la coerenza dell'interfaccia utente. Preferisco davvero raccomandare di usare gli stessi metodi in tutti gli stati (generando alla fine messaggi come "Funzionalità non disponibile. Devi acquistare la funzione ...") e, se necessario, fornire funzioni come hasFeatureX() per aiutare l'app a decidere. Questo sarebbe molto più manutenibile: se introducessi nuove funzionalità a pagamento (con un prezzo diverso), o se avessi ruoli speciali (ad es. "Auditor", "Amministratore", ecc ...) sarebbe più conveniente facile da definire quale stato consente l'accesso a quale caratteristica.

Infine, potresti pensare di utilizzare il modello di strategia (di nuovo in base all'utente o allo stato dell'app). Ma le strategie non sono stati, quindi questo approccio non funzionerebbe se si hanno alcune cose da eseguire per garantire una corretta transizione di stato. Funziona solo se gli algoritmi sono veramente intercambiabili.

Lasciando da parte i pattern nominati per un momento, inizierei con qualcosa di simile.

L'idea generale qui è che il tuo utente ha un abbonamento, che ha un livello di iscrizione. L'oggetto di sottoscrizione può includere un intervallo di tempo (che consente di verificare la scadenza).

In base al resto del modello, creerai un servizio che restituisca le risposte sul fatto che un utente abbia o meno accesso a una determinata funzione in base alla sua iscrizione.