Diciamo che ho un prodotto con caratteristiche diverse o accesso a funzioni diverse a seconda delle cose (cioè Utente Premium, Beta, Demo, Utente connesso, ecc.).
Qual è il modo migliore per organizzare un sistema dove non è un insieme di controlli statici (ad esempio un gruppo di istruzioni if, ad esempio)?
La piattaforma non è importante, sto chiedendo appunto i principi di progettazione / progettazione generale.
Il modello di progettazione Proxy potrebbe essere un interessante punto di partenza. Una delle varianti descritte in Design Patterns: Elements of Reusable Object-Oriented Software è chiamato proxy di protezione, progettato per il controllo degli accessi quando diversi oggetti devono avere diritti di accesso diversi. Il pattern Decorator potrebbe anche essere interessante, soprattutto perché un "proxy di protezione potrebbe essere implementato esattamente come un decoratore".
Suppongo che tu rappresenti il tuo Utente come un oggetto. Un proxy di protezione per eseguire l'autenticazione o un decoratore per aggiungere diritti / privilegi aggiuntivi sembra una soluzione naturale. Ma senza sapere come stai rappresentando il tuo utente e come interagisce con altri aspetti del tuo sistema, è difficile dire qualcosa di più concreto.
Vorrei iniziare creando un modello, di couse. Crea la tua logica di business, accesso ai dati, crea alcune classi base, ecc ... Tienilo libero quando vedi che il design potrebbe essere migliore.
Ci sono due approcci generali per risolvere questo problema
Sulla base della tua menzione di diverse funzionalità per gli utenti beta, potresti prendere in considerazione l'idea di organizzare le funzionalità in moduli separati. Ciò ti consentirà di controllare quale funzionalità viene ricevuta senza dover duplicare i percorsi del codice (vecchio percorso, nuovo percorso) nei nuovi moduli.
Utilizzare una chiave di licenza per abilitare la funzionalità beta funzionerebbe se la funzionalità fosse nuova per l'applicazione.
Un buon esempio di questa configurazione sarebbe un elenco di controllo di accesso (ACL). Zend Framework ( link ) ha un componente di permessi che implementa questo tipo di installazione. La scomposizione generale è che alcuni modelli implementano un'interfaccia Role e altri modelli implementano un'interfaccia Risorse. Viene creato un elenco (utilizzando un modello di registro tramite la configurazione del file o nel codice) che definisce se un ruolo può accedere a una risorsa e dispone di un privilegio specifico. Mi piace pensare ai privilegi come a una lista di azioni. C'è molto da esplorare in quel componente.
<?php
//$acl has been previously defined and loaded
echo $acl->isAllowed('someUser', 'someResource', 'somePrivilege') ? 'yup' : 'nope'; ?>
//$user is currently not logged in and has a 'guest' role
if ($acl->isAllowed($user->getRole(), 'paidArticles', 'view') {
//Show the paid articles, secrets and all that
} else {
//Only show free articles
}
if ($acl->isAllowed($admin->getRole(), 'userList', 'delete') {
//Allow $admin to delete users from the list
} else {
//Perhaps log that someone is trying to access something they shouldn't
}
?>
Mentre mi rendo conto che questo è, o potrebbe trasformarsi in un insieme complesso di If-Thens, a un certo punto dovrai avere un metodo per dire "Se l'accesso è consentito, quindi mostra X contenuto / widget / etc" . Se le autorizzazioni sono abbastanza semplici, dovrebbe rimanere semplice. Penso che il vantaggio principale qui sia quello di permettere un piuttosto semplice isAllowed () e di darti un vero / falso basato sul fatto che tu abbia i ruoli, le risorse e l'impostazione delle azioni. Passato è molto flessibile su ciò che fai mentre esegui una query sull'ACL.
Leggi altre domande sui tag design features design-principles