Creare un diagramma di flusso per dimostrare il comportamento di chiusura

Question

Creare un diagramma di flusso per dimostrare il comportamento di chiusura

#1 da (2 voti)

0

Ho visto la domanda del test qui sotto l'altro giorno in cui gli autori hanno usato un diagramma di flusso per rappresentare la logica dei loop e ho pensato che sarebbe stato interessante farlo con una logica più complessa. Ad esempio, la chiusura in questa espressione di funzione immediatamente invocata ( IIFE ) è una sorta di boggles:

while (i <= qty_of_gets) {
    // needs an IIFE
    (function(i) {
        promise = promise.then(function(){
            return $.get("queries/html/" + product_id + i + ".php");
        });
    }(i++));                       
}

Mi chiedo se vedere una rappresentazione del diagramma di flusso di ciò che accade in esso potrebbe essere più illuminante. Potrebbe essere una cosa del genere? Sarebbe utile o semplicemente disordinato? Non ho la più pallida idea da dove cominciare, ma ho pensato che forse qualcuno avrebbe voluto fare una pugnalata. Probabilmente tutto l'ajax potrebbe andare e potrebbe essere solo un semplice ritorno all'interno dell'IIFE.

programming-practices javascript closures flowchart

posta 1252748 24.06.2013 - 21:21

fonte

1 risposta

Leggi altre domande sui tag programming-practices javascript closures flowchart

Rappresentazione dei dati nell'applicazione rispetto al database [chiuso] Sincronizza file csv usando nodejs

score 2 · Answer 1

Sfortunatamente, non penso che un diagramma di flusso sarebbe molto utile per questo problema, perché il codice sfrutta alcuni dettagli del linguaggio Javascript che ritengo sia piuttosto difficile rappresentare in modo efficace in un diagramma di flusso, come le funzioni di prima classe e portata variabile. Mi aspetto che sia facile usare i diagrammi di flusso per rappresentare un sottoinsieme di codice Javascript, ma doloroso e inutile (perché il diagramma di flusso sarebbe complesso) per rappresentare altro codice. Probabilmente potresti creare un chiaro diagramma di flusso per ciò che il codice è supposto fare (ignorando i dettagli di come funziona intorno a Javascript).

Sebbene le forme testuali creino una serie di problemi (come il tuo), sembrano essere il modo più efficace di scrivere programmi. Dico questo non perché spero sia vero (non lo so) o che penso che sarà sempre così, ma perché non ho mai visto un modo migliore di rappresentare la programmazione, nella sua complessità, ma attraverso il testo semplice . Sfortunatamente, progetti puliti come questo non sembrano aver preso piede. Forse cambierà presto.

Lasciatemi menzionare che non sono un esperto - la mia unica esperienza su questo argomento è l'utilizzo di LabView, con cui alla fine sono diventato disgustato a causa della difficoltà di implementare anche semplici logiche e funzioni, per non parlare di astrazioni sostanziali.

Detto questo, il codice è estremamente difficile da capire, perché:

devi pensare se le chiusure sono "per riferimento" o "per valore" (le metto tra virgolette perché non sono sicuro di quali siano i termini corretti). Questo è qualcosa che i programmatori Javascript hanno spesso problemi con. Credo che la funzione esterna sia specificamente in grado di risolvere questo problema, poiché viene immediatamente eseguita.

Puoi esaminare questo problema confrontando i seguenti due frammenti di codice:
```
var fs = [],    i = 0;
while (i <= 4) {
    (function(i) {
        fs.push(function(){
            return i;
        });
    }(i++));                       
}


var gs = [],    j = 0;
while (j <= 4) {
    gs.push(function(){
        return j;
    });
    j++;               
}
```
Quindi esegui alcune delle funzioni in fs e gs . Perché i risultati sono quelli che sono?
nidificato è relativamente difficile da comprendere e in genere oscura la soluzione. Per fare un confronto, i cicli annidati sono relativamente difficili da comprendere, così come gli oggetti / classi annidati, le tabelle nidificate, ecc. Le chiusure annidate indicano che ci sono più ambiti e tempi di esecuzione a cui pensare.
i è ombreggiato e non vedo davvero alcuna buona ragione per quello. Ora, in ogni ambito, devi capire a quale% di co_de viene fatto riferimento. Ahia. Poveri gattini .