Quali sono le buone pratiche comuni per gestire la disabilitazione / abilitazione degli elementi di funzionalità nelle applicazioni GUI per licenze / permessi diversi?

1

Ho lavorato su due diverse applicazioni desktop e entrambe avevano il problema di abilitare / disabilitare funzionalità e elementi della GUI associati, a seconda delle licenze disponibili o dei "ruoli utente".

Nella prima applicazione su cui ho lavorato, è stato creato un pasticcio ingombrando il codice con condizionali che controllavano determinate licenze. Ora lavoro su un'altra applicazione per cui il lavoro è appena iniziato e dove si è verificato un problema simile. Ora sto cercando un buon modo per risolvere il problema in un modo "migliore".

I problemi con il sistema che avevamo erano:

  • Abbiamo avuto molte molte posizioni nel codice che assomigliavano a if( !check_license( MY_LICENSE ) ) myWidget->setVisible(false);
    o
    if( !check_license( MY_LICENSE ) ) return;
    Questo tipo di linee ingombrava il codice in molti punti ed era difficile da mantenere quando una funzionalità doveva essere disabilitata / abilitata per una determinata licenza.

  • Gli addetti alle vendite hanno spesso chiesto: "Posso fare questo e quello con la licenza xy?" Avevamo un tavolo in una wiki che tentava di risolvere quel problema, ma era piuttosto a grana grossa, quindi spesso dovevamo esaminare il codice per trovare la risposta.

Quindi ecco la domanda:
Come ridurre l'effetto "ingombro" e quali sono i modi migliori per avere un registro centrale per gli elementi di funzionalità.

Penso che la soluzione dovrebbe contenere i seguenti concetti.

  • La nozione di un elemento di funzionalità, che è esplicitamente menzionato nel codice.
  • La nozione di blocco di funzionalità a cui possono essere assegnati più elementi di funzionalità.
  • Un'entità "FunctionalityRegister" che consente di registrare elementi di funzionalità con blocchi di funzionalità che possono stampare un elenco di elementi di funzionalità per ciascun blocco di funzionalità
  • Un'entità che può essere richiesta se un elemento di funzionalità è attualmente abilitato

Non ho idee concrete su come ridurre il numero di posti in cui il programma chiede se un elemento di funzionalità è abilitato. Mi piacerebbe qui le tue idee su questo problema.

Mi piacerebbe anche vedere le congestioni per le tecniche che riducono la "dimensione del codice" di una richiesta di abilitazione su un minium. Questo dipende dalla tecnologia utilizzata, quindi devo menzionare che usiamo C ++ / Qt.

In che modo è stato risolto il problema nelle applicazioni che conosci e in che modo i vantaggi e gli svantaggi?

    
posta Knitschi 23.10.2015 - 12:01
fonte

1 risposta

1

I have not concrete ideas how one can reduce the number of places where the program asks if an functionality item is enabled.

Non è necessario. Se una funzionalità comporta modifiche all'interfaccia utente in 7 posizioni, allora deve essere 7 posti che controllano haveFeature(Bit.TIME_TRAVEL) nel codice di base. Questa non è una violazione di DRY.

Quale dovrebbe essere ridotto, preferibilmente a 1, è il numero di posti che determinano il comportamento di haveFeature() . Idealmente, sia la base di codice che il supporto dell'utente useranno questa conoscenza da uno stesso documento autorevole. Ad esempio, potresti mantenere una lista / foglio di calcolo / coreografia interpretativa di danza / qualunque sia nel tuo repository controllato dalla versione e generare automaticamente sia la pagina web interna di supporto dell'utente che il codice decisionale in haveFeature() da esso, come una parte normale del processo di compilazione.

    
risposta data 23.10.2015 - 12:15
fonte

Leggi altre domande sui tag