Gestione di if-statement con una durata nota [duplicato]

1

Non sapevo esattamente come chiamare queste situazioni, quindi lo illustrerò.

Se ho qualcosa di simile in un metodo:

if (i <= 5) 
    doSomething();
else 
    doSomethingElse();

ma so che i non sarà mai inferiore o uguale a 5 una volta che supera 5, non è più necessario continuare a controllare l'if-statement una volta che si è staccato la prima volta.

È una buona idea implementare un modello di strategia in questo caso, per evitare controlli ridondanti?

class strategy1 implements strategy {

    Object obj; // stores a reference to the object that uses it

    void run() {
       if (i <= 5)
            doSomething();
        else {
            obj.strategy = new strategy2(obj);
            obj.strategy.run();
        }
    }
}

class strategy2 implements strategy {

    void run() {
        doSomethingElse();
    }

}

e l'oggetto chiama semplicemente strategy.run()

Credo che questo sacrifichi una certa leggibilità e semplicità per le prestazioni, ma rende anche chiaro che i non scenderà al di sotto di 6 una volta che avrà raggiunto 6, il che fornisce alcune informazioni in più rispetto alla sola istruzione if. C'è un modo migliore?

    
posta Ryan 22.07.2015 - 20:18
fonte

3 risposte

6

Quello che stai proponendo sembra un Sostituisci il Codice Tipo [o un condizionale] con Stato / Strategia refactoring .

Possibili ragioni per farlo:

  1. I condizionali sono diventati complessi o si prevede che diventino complessi in futuro.
  2. I condizionali comportano ritardi o risorse fiscali.

Motivi per non farlo:

  1. I condizionali sono semplici al momento e non ci si aspetta che i condizionali diventino complicati in futuro.
  2. La valutazione dei condizionali non comporta ritardi apprezzabili e non applica altre risorse.

Al momento, il% condizionale dii < 5 si adatta a entrambi i motivi per non aver effettuato questo refactoring.

p.s. Penso che quello che stai descrivendo sia una specie di pattern stato piuttosto che pattern stategy . Detto questo, lo stato e strategia i modelli hanno meccanismi interni simili. Basta scegliere la terminologia.

    
risposta data 22.07.2015 - 20:30
fonte
3

Il codice più semplice per fare il lavoro è il migliore.

La prima versione funziona. Ed è molto semplice: tutto ciò che deve fare è valutare quale delle due funzioni chiamare e poi chiamare quella giusta. Poca possibilità di errore. Banale da cambiare se la determinazione di cosa chiamare cambia.

Ora stai complicando le cose. presumi che una volta chiamata la seconda funzione, la condizione non sarà mai tale che la prima funzione debba essere richiamata di nuovo. Questa è una grande ipotesi, e "mai" è un tempo molto lungo. Quanto ti darai a calci se si scopre che posso essere resettato a 1, e il tuo codice si rompe, e l'unico modo per risolverlo è rimuovere il tuo codice intelligente e reintrodurre il semplice controllo? Quanto vorrà I voler calciare tu se il tuo codice intelligente porta a questo bug, ed è mio compito ripararlo?

    
risposta data 23.07.2015 - 00:54
fonte
0

Mi avvicinerò da un lato diverso delle cose - in questo caso avrai il vantaggio di previsione ramo . Se dici di avere una sequenza ordinata, questa dovrebbe essere l'ideale nel tuo caso.

L'idea è la tua originale se la dichiarazione sarà estremamente veloce prima del crossover e poco dopo. Quindi, è probabile che sarà più veloce di avere effettivamente una logica attorno ad esso.

Il modo in cui funziona la previsione delle branchie è che il tuo processore cercherà di indovinare l'esito della base della dichiarazione senza i risultati passati e di precaricare le seguenti dichiarazioni di conseguenza. Se la tua sequenza è ordinata, il tuo processore sarebbe corretto al 99,9999% delle volte, tranne un paio di volte dopo il crossover, che in realtà ti aumenta la velocità.

    
risposta data 23.07.2015 - 01:52
fonte

Leggi altre domande sui tag