Domanda

Ho una domanda generica su ambito e incapsulamento. Prendi due scenari:

Scenario 1:

// a global application level constant
public static const IS_DEMO_MODE:Boolean = false;   

... // somewhere deep in the codebase

private function _myFunction():void
{
    if (IS_DEMO_MODE == true) {
      // If Demo Mode do not allow this function to complete
      return;       
    }
    else {
       // Function behaves normally
       // Code ...
    }

}

Scenario 2:

// a global application level constant
public static const IS_DEMO_MODE:Boolean = false;   

... // somewhere deep in the codebase

 // call the function and pass in the constant
_myFunction(IS_DEMO_MODE);


private function _myFunction(isDemoMode:Boolean):void
{
    if (isDemoMode == true) {
      // If Demo Mode do not allow this function to complete
      return;       
    }
    else {
       // Function behaves normally
       // Code ...
    }

}

Funzionalmente parlando, questi due frammenti di codice fanno esattamente la stessa identica cosa. Sto cercando di capire i punti più fini dello stile di codifica e perché un modo potrebbe essere preferito all'altro? Sembra che lo scenario 2 sia migliore dal punto di vista dell'incapsulamento. Ma lo scenario 1 è più infallibile in quanto il booleano che si trova nel condizionale proviene da un solo posto, la costante globale. Non devi preoccuparti di una chiamata di funzione che durante la corretta ricezione di un parametro potrebbe passare nel valore errato. Ma lo scenario 2 sembra utile perché rimuovi la dipendenza della costante e puoi far sì che la funzione si comporti in modo più dinamico. Qualche idea su questo? Ci sono altri compromessi che sto cercando?

Stesso concetto e domanda applicati anche a oggetti e classi. Ma presento l'esempio in termini di una funzione per semplicità dell'esempio di codice.

È stato utile?

Soluzione

Nel secondo approccio è possibile rendere _myFunction in un modulo separato, senza dipendenza da quello globale - quindi è più facile da testare, più facile da riutilizzare e ti aiuta a controllare il tuo grafico delle dipendenze , che spesso diventa un problema serio in basi di codice di grandi dimensioni. Se inserisci dipendenze che potresti facilmente evitare, stai solo peggiorando il problema del grafico delle dipendenze e pochissimi benefici potenziali potrebbero mai pagare per QUELLO.

In effetti, per ottenere questo tipo di vantaggi, un grande modello di dipendenza è esplicitamente l'oggetto INJECT che altrimenti creerebbe dipendenze (generalmente indesiderabili e indesiderate) tra i moduli - vedi qui per iniziare. Come fanatico dei test, dell'accoppiamento lento e del riutilizzo, sto gradualmente diventando anche un fanatico dell'iniezione di dipendenze, quindi non SOGNO di accedere a una costante globale in cui passarla come argomento è un'alternativa ovvia ...; - ).

Altri suggerimenti

2 sarebbe preferibile se si desidera collegare la stessa unità di compilazione a entrambe le versioni (specialmente come libreria condivisa in un percorso fisso a livello globale) o se si eseguono più istanze nello stesso processo. Altrimenti, se ti trovi in ??una situazione in cui ricostruire tutto dalla fonte non è un ostacolo, il numero 1 è meglio.

Alcune cose sono davvero globali. Le costanti globali non sono affatto pericolose.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top