Prova e rimuovi o rimuovi sempre

2

Ho una funzione per mostrare o nascondere un determinato controllo dell'interfaccia utente. Nel mio esempio qui di seguito, il framework è jQuery che sto usando per un evento per mostrare un suggerimento che può sparare un LOT (basato sui movimenti del mouse) - ma il problema sottostante è più generale e può anche presentarsi in modo simile in molti altri framework UI. In effetti, il problema potrebbe essere ancora più generalizzato a qualsiasi tipo di componente con due stati da cambiare spesso, non solo i componenti dell'interfaccia utente.

Si consideri:

Codice A:

$(this).plothover(function(item) { 
   if(item&&item!="undefined"){
      show tooltip
   }
   else 
     remove tooltip
});

Codice B:

$(this).plothover(function(item) { 
   if(item&&item!="undefined"){
      show tooltip
   }
   else {
      if(tool tip is shown){
           remove tooltip
      }
   }
});

item esisterà in punti cartesiani definiti dove esistono punti dati (cioè, coordinate grafiche su una tela). In altre parole, le probabilità sono ~ 10000: 1 nel favore della condizione else che spara su una base DPI .

Mentre il mouse si muove,

Il codice A lo rimuove senza tenere conto di alcuna condizione Il codice B lo rimuove solo se era già stato creato, ma deve prima verificare la creazione

Quindi, che è considerato 'giusto'? Blind nasconde il controllo se è visibile o no, o lo nasconde solo se è visibile?

L'ho analizzato con jsperf e le differenze sono insignificanti per quanto riguarda le prestazioni, ma tendono a distruggere i ciechi. Ma se è "sbagliato" dalla teoria farlo, preferirei scegliere la via migliore.

--- MODIFICA --- Per chiarire, l'effettiva chiamata non è importante (cioè, come viene rimossa). Né sto cercando una revisione del codice. L'esempio sopra riportato è una delle molte volte in cui mi sono imbattuto in questo caso.

Piuttosto, desidero discutere la teoria implicata in "Distruggi ciò che può esistere" o "cerca e distruggi se esiste".

    
posta briansol 13.01.2015 - 21:11
fonte

3 risposte

0

Ecco il mio post di Code Review che ho postato prima che la domanda venisse chiusa lì:

Perché testare in primo luogo? Quando stai cercando di evitare un'operazione costosa, una che è significativamente più costosa del test stesso.

Il tuo guadagno in termini di prestazioni deriva dal chiamare selettivamente la rimozione e ottenere il tempo non speso rimuovendolo sempre.

Quindi la tua risposta è data da 2 azioni, test e rimozione, e p la probabilità del tooltip mostrato, testare e rimuovere quando time (remove) > time (test) + p * time (remove).

Che è esattamente il motivo per cui la rimozione è importante.

    
risposta data 30.01.2015 - 20:01
fonte
1

Quando ci sono due alternative uguali per implementare qualcosa, dove è necessario più codice e il secondo meno (e "meno codice" è in effetti più semplice, non un "trucco intelligente" che sottolinea la tua mente), in genere preferirei il più semplice uno più complicato. Più facile da leggere e comprendere, più facile da gestire, più facile da modificare.

Ovviamente, in un caso come quello mostrato sopra, si è sicuri che l'API del componente che si sta utilizzando consente di applicare "rimuovi" indipendentemente dal suggerimento che deve essere mostrato prima e che si può veramente lasciare Esegui il test senza introdurre un bug (se il design dell'API è sano di mente, è possibile che IMHO lo aspetti, ma non tutte le API sono solide). D'altra parte, l'aggiunta di un test come if(tool tip is shown) sebbene non sia necessario mostra che non hai compreso pienamente l'API e ti lascia un cattivo esempio se stai per scrivere di nuovo uno snippet di codice simile più tardi.

    
risposta data 13.01.2015 - 22:19
fonte
0

Hai design pattern (composito, memento, singletom ...), hai principi di OOD (SRP, Dry, LSP ...) e hai tattiche (CJ, Paranoid, NAG ...). I due esempi seguono diverse tattiche.

Le tattiche decidono se hai bisogno di prestazioni, registrazione o leggibilità. In genere sono specificati dagli sviluppatori senior o CTO.

Perché dici che la performance è trascurabile e il suo Javascript, quindi siamo in View of MVC e sei vicino all'Utente consiglierei questo stile NAG (permetto anche di usare un po 'OOP):

function ToolTipAppearanceManager(){
  /** @param show {Boolean} <code>true</code> to let it appear, 
   *                        <code>false</code> to hide.
   */
  this.setVisible = function(show){
    if (show){
      if (tool tip is shown) {
          if(console && console.warn)console.warn('Already visible. Maybe bug!');    
      }
      show tooltip;
    } else {
      if (not tool tip is shown){
          if(console && console.warn)console.warn('Already removed. Maybe bug!');    
      } 
      remove tooltip;
    }

  }
}
var appMan = new ToolTipAppearanceManager();
$(this).plothover(function(item) {
   appMan.setVisible(item && item != "undefined");
});
    
risposta data 14.01.2015 - 15:20
fonte

Leggi altre domande sui tag