Flag booleani in Presenter per controllare il flusso di esecuzione

0

Riesco a vedere le persone che usano boolean di flag, specialmente in Controllers / Presenters , per controllare il flusso di esecuzione. Ad esempio,

public void onButtonClicked() {
    hasButtonClicked=true
    // code here
}

Poi più tardi, in un metodo non correlato, ma sempre dello stesso Presenter , questo flag viene utilizzato come segue:

public void onSomeOtherActionHappened() {
    if (hasButtonClicked) {
    // execute this
    } else {
    // execute that
    }

}

Non solo rende più difficile testare l'unità, è anche difficile seguire l'intenzione della bandiera e quando cambia il suo stato.

Mi sa solo di odori. Normalmente sostituisco tali flag con Object s che facilita realmente i test delle unità. Eppure, mi chiedo ancora, c'è qualcosa a cui l'umanità ha già pensato, sarebbe possibile evitare di usare tali flag per rappresentare uno stato, come affrontarlo in modo diverso e come spiegare perché odora. Grazie.

    
posta Eugene 19.02.2016 - 20:26
fonte

1 risposta

1

Non c'è niente di sbagliato nei booleani. Non c'è niente di sbagliato nel flusso di controllo. Questa è solo la programmazione del computer per te. Ci sono casi in cui l'uso ripetuto di un condizionale è meglio sostituito dal polimorfismo, ma questa non è la norma.

Un condizionale in un metodo non è affatto problematico, a condizione che la complessità ciclomatica complessiva sia ancora sufficientemente bassa per essere facilmente testabile. Se il condizionale è molto grande e le due diramazioni sono piuttosto diverse e non hanno paralleli o interazioni chiari, sono meglio estrapolate in metodi di supporto privati che puoi testare separatamente (sì, ti preghiamo di testare i tuoi metodi privati). Tuttavia, introdurre oggetti separati e gestire il condizionale tramite il polimorfismo è nella maggior parte dei casi molto meno ovvio e il codice non ovvio è un codice pericoloso. Il tuo flusso di controllo è improvvisamente implicito e si sviluppa su più classi. Ciò rende i sistemi "orientati agli oggetti" di grandi dimensioni estremamente difficili da leggere o eseguire il debug, con un marginale aumento della testabilità, il codice spaghetti del nostro tempo.

Quindi, a meno che tu non abbia una buona ragione per fare il refactoring condizionale, lascialo lì.

    
risposta data 19.02.2016 - 21:02
fonte

Leggi altre domande sui tag