Design Pattern per chiedere agli utenti chiarimenti con uno dei vari tipi di UI

Question

Design Pattern per chiedere agli utenti chiarimenti con uno dei vari tipi di UI

#1 da (4 voti)

1

Sto lavorando su un programma che ha molti frontend. L'applicazione principale ha una GUI che consente un sacco di interazione manuale dell'utente. Il secondo è più simile a uno script che esegue solo un flusso di lavoro predefinito.

A un certo punto potrebbero apparire domande all'utente. Questi sono più spesso legati a dati di input ambigui, in cui l'utente deve decidere su una delle possibilità. Le ambiguità spesso provengono dal formato dati di un programma esterno, quindi non è possibile eliminarle semplicemente.

Il modo più semplice per ottenere l'input dell'utente è semplicemente aprire una finestra di messaggio con le opzioni disponibili. Preferirei comunque avere diverse classi che gestiscono questo. Uno che crea una finestra di dialogo della GUI, una che richiede le opzioni sulla CLI e una che risponde solo dalle decisioni preregistrate (ad es. Per il test).

Le due possibilità che vedo hanno un singleton che memorizza un oggetto della classe desiderata o lo passa attraverso l'intera gerarchia di chiamate per ogni piccola classe che può sollevare una domanda.

Esistono modelli di progettazione o best practice su come risolvere questo problema? Mi sembra un problema standard.

design-patterns user-interface

posta Tim 16.10.2017 - 10:47

fonte

1 risposta

Leggi altre domande sui tag design-patterns user-interface

Quali sono i vantaggi di un ciclo foreach rispetto a un ciclo for body-less Limiti dell'iniezione di dipendenza

score 4 · Accepted Answer

Questo problema si adatta bene al modello di strategia:

several classes handling that. One that creates a GUI dialog, one that asks for the options on CLI and one that just answers from prerecorded decisions (e.g. for testing).

Avresti un'interfaccia AskUserForChoice e varie strategie di interfaccia utente che la implementano. Quando l'applicazione viene avviata, è configurata con una strategia appropriata.

Quindi, come possiamo portare l'implementazione della strategia nel luogo in cui viene utilizzata?

The two possibilities I see are having a singleton that stores an object of the desired class or passing it through the whole call hierarchy for every tiny class that may raise a question.

Solitamente i single sono considerati un anti-modello. Oscurano le reali dipendenze del tuo codice e rendono più difficili i test.

Le dipendenze che passano esplicitamente attraverso tutte le chiamate di funzione rendono tutte le dipendenze molto esplicite. Questa è inizialmente una strategia praticabile.

Tuttavia, diverse parti del codice hanno responsabilità diverse. Non si dovrebbe dovere passare esplicitamente una strategia GUI attraverso il codice di livello aziendale. Invece, vorrei introdurre un oggetto User Interface. Questo oggetto offre metodi per codice di logica aziendale che raggiungono un particolare obiettivo del livello aziendale, ovvero ui.resolveAmbiguity(a, b, c) non ui.showOptionDialog("Please select one option to resolve the ambiguity:", a, b, c) . Internamente, l'oggetto User Interface può essere configurato con una particolare strategia per visualizzare queste scelte. Poiché tutte le operazioni dell'interfaccia utente sono state raggruppate in una singola classe, il passaggio di questa dipendenza è abbastanza gestibile.

Se non si desidera gestire le dipendenze in modo esplicito passando oggetti come parametri di funzione o argomenti del costruttore, è preferibile utilizzare un framework di iniezione delle dipendenze esistente che collega automaticamente le dipendenze necessarie. Sebbene tali framework possano utilizzare internamente i singleton, possono anche avere tooling e funzionalità per ridurre i loro inconvenienti ed evitare "azioni a distanza".

Ma per le piccole applicazioni, la gestione manuale delle dipendenze attraverso un design pulito è spesso del tutto sufficiente, senza bisogno di strutture.