Come "tradurre" gli stati di oggetti interdipendenti nel codice?

3

Ho il seguente problema. La mia interfaccia utente contiene diversi pulsanti, etichette e altre informazioni visive. Sono in grado di descrivere ogni possibile scenario di flusso di lavoro che dovrebbe essere consentito su quell'interfaccia utente. Ciò significa che posso descriverlo in questo modo - quando si preme il pulsante A, dovrebbe seguire quanto segue - >

Nel caso di quel pulsante A, ci sono tre fattori indipendenti che influenzano il possibile risultato quando si preme il pulsante A. Lo stato della sessione (vuoto, singolo, multi, multi speciale), il lavoro effettivo che viene fatto dal sistema al momento di premere il pulsante A (non stava accadendo nulla, il lavoro era in corso, il lavoro era in pausa) e un elemento UI separato che ha due stati (on, off). Questo mi dà un cubo tridimensionale con 24 possibili risultati.

Potrei scrivere codice per questo usando se cicli, cicli di commutazione ecc .... ma il problema è che ho altri 7 pulsanti su quell'interfaccia utente, posso inserire questa UI da stati diversi ... alcuni pulsanti cambiano lo stato, alcuni parametri di modifica ... Per riassumere, le combinazioni sono un matto e non sono in grado di trovare una metodologia che sia scalabile e sia sistematicamente affidabile. Sono in grado di descrivere OGNI flusso di lavoro con le parole, sono sicuro che la mia descrizione è completa e senza errori logici. Ma non sono in grado di tradurlo in codice. Stavo cercando di disegnare diagrammi di flusso, ma presto è diventato visivamente troppo complicato a causa di troppi "emafors". Puoi consigliare come procedi?

    
posta Earl Grey 02.04.2012 - 14:47
fonte

4 risposte

4

non provare a combinare tutto in un unico punto

se un pulsante cambia un parametro lascia che cambi il parametro (e nient'altro)

se un pulsante utilizza un parametro, lascia che richieda il parametro

questo è chiamato limitazione della responsabilità

modifica: il fatto che tu stia cercando di visualizzare tutte le possibilità di un'azione in un cubo è un indicatore del tentativo di guardare troppo in largo al flusso del tuo programma. molte volte ci saranno delle somiglianze tra questi risultati (per esempio, lo stato vuoto significa che non dovrebbe accadere indipendentemente di quali siano gli altri parametri)

anche provare a decentralizzare il codice dell'approccio OOP per questo: ogni stato ha il proprio codice da eseguire quando si preme il pulsante A; avere un'interfaccia State con il metodo buttonAPressed() (aggiungi i parametri se necessario) che gestisce tutto ciò che è specifico per lo stato e implementalo in modo diverso per vuoto, singolo, multi, multi speciale

    
risposta data 02.04.2012 - 15:08
fonte
1

A volte, con funzionalità complesse arriva un'implementazione complessa. Dal momento che la reazione dell'interfaccia utente all'input dell'utente dipende da così tante variabili, potresti semplicemente accettare che il tuo codice non sarà breve, dolce e semplice.

Potrebbe essere necessario disporre di una funzione separata per gestire ciascun componente dell'interfaccia utente e incapsularlo in questo modo. Quindi, ognuna di queste funzioni agisce come un gestore di eventi che guarda cosa sta succedendo nell'ambiente prima di agire sull'input dell'utente.

Un'altra opzione è codificare ogni componente dell'interfaccia utente come una classe separata che forse si specializza e eredita da una classe di componente UI comune. In questo modo, ogni componente dell'interfaccia utente ha le sue proprietà, metodi e stato. Questa potrebbe essere la soluzione migliore per mitigare la complessità del tuo design.

    
risposta data 02.04.2012 - 15:03
fonte
1

Se stai cercando un formalismo, controlla alcuni approcci grafici:

Esistono molti altri.

Metterei l'intera logica di stato in un controller e l'interfaccia utente stessa in una vista, utilizzando un model-view-controller architettura.

    
risposta data 02.04.2012 - 15:12
fonte
1

the problem is, I have another 7 buttons on that ui, I can enter this UI from different states..some buttons change the state, some change parameters... To sum up, the combinations are mindbogling and I am not able come up with a methodology that scales and is systematically reliable. I am able to describe EVERY workflow with words, I am sure my description is complete and without logical errors. But I am not able to translate that into code.

Sembra che dovresti esaminare lo schema stato o mediatore modello. Se il tuo programma ha già tutti questi stati, immagina quanti ne potrebbero avere dopo altri 2-3 anni di funzionalità aggiunte. Potrai seguire nuove transizioni e stati facilmente se segui il modello di stato.

I modelli di design si applicano in realtà molto bene, più il problema è complesso. Avere la lungimiranza di vedere i problemi di estensibilità e provare ad applicarne uno adatto si ripaga in futuro.

    
risposta data 02.04.2012 - 15:12
fonte

Leggi altre domande sui tag