Utilizzo dei flag "impedisce l'esecuzione del metodo"

Question

Utilizzo dei flag "impedisce l'esecuzione del metodo"

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

4

Prima di tutto voglio sottolineare la mia preoccupazione con qualche pseudocodice (penso che capirai meglio)

Supponi di avere un flag di debug globale o una variabile di classe chiamata "debug",

class a :
   var debug = FALSE

e lo usi per abilitare i metodi di debug. Ci sono due tipi di utilizzo come so:

prima in un metodo:

 method a :
      if debug then call method b;

 method b :

secondo nel metodo stesso:

 method a : 
       call method b;

 method b :
      if not debug exit

E voglio sapere, c'è qualche Ipo file o stack pointer, una saggia differenza tra questi due approcci. Quale utilizzo è migliore, più sicuro e perché?

methods variables design-patterns memory

posta tpaksu 26.03.2012 - 20:05

fonte

3 risposte

1

Ignorare le ottimizzazioni del compilatore, ovviamente test per evitare una chiamata di funzione (la prima soluzione) può evitare qualsiasi sovraccarico è associato con la chiamata di funzione. Tuttavia, questo non è specifico per i flag di debug globali, ed è certamente una piccola cosa nel quadro generale. Se hai qualche motivo per preferire la seconda soluzione, va bene. Preoccupati per altre cose.

risposta data 26.03.2012 - 21:35

fonte

0

Primo metodo: O (n) nei metodi * O (m) nei siti di chiamata.

Secondo metodo: metodi O (n).

È chiaro che il primo metodo richiede troppa codifica e viola DRY dappertutto.

risposta data 26.03.2012 - 22:52

fonte

Leggi altre domande sui tag methods variables design-patterns memory

Sistema di apprendimento invece di usare sed / replace per rivedere i risultati dei test Client JavaScript per parlare con il server WCF con associazione WebSockets

score 1 · Accepted Answer

Per prima cosa, non penso che dovresti preoccuparti della velocità qui. La mia preoccupazione principale sarebbe quella di progettare un'API appropriata, altrimenti la velocità non sarebbe un problema perché nessuno lo userebbe effettivamente. Anche se questo è solo per un'applicazione interna, personalmente mi piace progettare le cose con l'intento che un giorno possano essere scomposti nella propria libreria.

Quindi quali sono i compromessi API? Se dovresti essere in grado di chiamare il metodo b senza averlo controllato lo stato della variabile di debug, il secondo esempio non è un'opzione. Potresti anche preoccuparti se la variabile debug fa parte o meno dell'API pubblica. Se lo è, esponendo un metodo isDebug e consentendo agli utenti di decidere quando il metodo b dovrebbe essere chiamato potrebbe avere senso. Tuttavia, se il metodo b non ha altro motivo di esistere se non quello di essere chiamato quando è attivo il debug, allora ha senso incapsulare il condizionale all'interno del metodo.