Perché un programma dovrebbe usare una chiusura?

Dopo aver letto molti post che spiegano le chiusure qui, mi manca ancora un concetto chiave: perché scrivere una chiusura? Quale compito specifico eseguirà un programmatore che potrebbe essere meglio servito da una chiusura?

Esempi di chiusure in Swift sono gli accessi di un NSUrl e l'uso del geocoder inverso. Ecco un esempio. Sfortunatamente, quei corsi presentano solo la chiusura; non spiegano perché la soluzione del codice sia scritta come una chiusura.

Un esempio di un problema di programmazione nel mondo reale che potrebbe innescare il mio cervello nel dire "aha, dovrei scrivere una chiusura per questo", sarebbe più informativo di una discussione teorica. Non mancano le discussioni teoriche disponibili su questo sito.

Prima di tutto, non c'è nulla di impossibile senza l'utilizzo di chiusure. Puoi sempre sostituire una chiusura con un oggetto che implementa un'interfaccia specifica. È solo una questione di brevità e riduzione dell'accoppiamento.

In secondo luogo, tenere presente che le chiusure vengono spesso utilizzate in modo inappropriato, in cui un semplice riferimento di funzione o un altro costrutto sarebbero più chiari. Non dovresti prendere ogni esempio che vedi come una buona pratica.

Il punto in cui le chiusure brillano su altri costrutti è quando si utilizzano funzioni di ordine superiore, quando è effettivamente necessario comunicare lo stato e è possibile renderlo univoco, come in questo esempio JavaScript dalla pagina di Wikipedia sulle chiusure :

// Return a list of all books with at least 'threshold' copies sold.
function bestSellingBooks(threshold) {
  return bookList.filter(
      function (book) { return book.sales >= threshold; }
    );
}

Qui, thresholdviene comunicato in modo molto succinto e naturale da dove viene definito a dove viene utilizzato. Il suo ambito di applicazione è precisamente limitato il più piccolo possibile. filternon deve essere scritto per consentire la possibilità di passare dati definiti dal cliente come una soglia. Non dobbiamo definire alcuna struttura intermedia al solo scopo di comunicare la soglia in questa piccola funzione. È completamente autonomo.

È possibile scrivere questo, senza una chiusura, ma richiederà molto più codice, e più difficile da seguire. Inoltre, JavaScript ha una sintassi lambda abbastanza dettagliata. In Scala, ad esempio, l'intero corpo della funzione sarebbe:

bookList filter (_.sales >= threshold)

Se puoi comunque usare ECMAScript 6 , grazie alle funzioni fat fat arrow anche il codice JavaScript diventa molto più semplice e può essere effettivamente inserito su una sola riga.

const bestSellingBooks = (threshold) => bookList.filter(book => book.sales >= threshold);

Nel tuo codice, cerca i luoghi in cui generi molta piastra della caldaia solo per comunicare valori temporanei da un posto all'altro. Queste sono eccellenti opportunità per considerare la sostituzione con una chiusura.

A titolo di spiegazione, prenderò in prestito un po 'di codice da questo eccellente post sul blog sulle chiusure . È JavaScript, ma è la lingua utilizzata dalla maggior parte dei post di blog che parlano di chiusure, poiché le chiusure sono così importanti in JavaScript.

Diciamo che volevi renderizzare un array come una tabella HTML. Potresti farlo in questo modo:

function renderArrayAsHtmlTable (array) {
  var table = "<table>";
  for (var idx in array) {
    var object = array[idx];
    table += "<tr><td>" + object + "</td></tr>";
  }
  table += "</table>";
  return table;
}

Ma sei in balia di JavaScript su come verrà reso ogni elemento dell'array. Se si desidera controllare il rendering, è possibile farlo:

function renderArrayAsHtmlTable (array, renderer) {
  var table = "<table>";
  for (var idx in array) {
    var object = array[idx];
    table += "<tr><td>" + renderer(object) + "</td></tr>";
  }
  table += "</table>";
  return table;
}

E ora puoi semplicemente passare una funzione che restituisce il rendering desiderato.

Che cosa succede se si desidera visualizzare un totale parziale in ogni riga della tabella? Avresti bisogno di una variabile per tracciare quel totale, vero? Una chiusura consente di scrivere una funzione di rendering che si chiude sulla variabile totale in esecuzione e consente di scrivere un renderer in grado di tenere traccia del totale parziale:

function intTableWithTotals (intArray) {
  var total = 0;
  var renderInt = function (i) {
    total += i;
    return "Int: " + i + ", running total: " + total;
  };
  return renderObjectsInTable(intArray, renderInt);
}

La magia che sta accadendo qui è che renderInt mantiene l'accesso alla totalvariabile, anche se renderIntviene ripetutamente chiamato ed esce.

In un linguaggio più tradizionalmente orientato agli oggetti rispetto a JavaScript, potresti scrivere una classe che contiene questa variabile totale e passarla invece di creare una chiusura. Ma una chiusura è un modo molto più potente, pulito ed elegante per farlo.

Ulteriori letture

• MDN sulle chiusure
• Come funzionano le chiusure JavaScript?

Lo scopo di closuresè semplicemente quello di preservare lo stato; da qui il nome closure: si chiude sullo stato. Per facilitare ulteriori spiegazioni, userò Javascript.

In genere hai una funzione

function sayHello(){
    var txt="Hello";
    return txt;
}

dove l'ambito delle variabili è associato a questa funzione. Quindi dopo l'esecuzione la variabile non txtrientra nell'ambito. Non è possibile accedervi o utilizzarlo al termine dell'esecuzione della funzione.

Le chiusure sono costrutti linguistici, che consentono - come detto prima - di preservare lo stato delle variabili e prolungare così l'ambito di applicazione.

Questo potrebbe essere utile in diversi casi. Un caso d'uso è la costruzione di funzioni di ordine superiore .

In matematica e informatica, una funzione di ordine superiore (anche forma funzionale, funzionale o functor) è una funzione che svolge almeno una delle seguenti operazioni: 1

• accetta una o più funzioni come input
• genera una funzione

Un esempio semplice, ma certamente non troppo utile è:

 makeadder=function(a){
     return function(b){
         return a+b;
     }
 }

 add5=makeadder(5);
 console.log(add5(10)); 

Si definisce una funzione makedadder, che accetta un parametro come input e restituisce una funzione . Esiste una funzione esternafunction(a){} e una interna. function(b){}{} Inoltre definisci (implicitamente) un'altra funzione add5come risultato della chiamata alla funzione di ordine superiore makeadder. makeadder(5)restituisce una funzione anonima ( interna ), che a sua volta accetta 1 parametro e restituisce la somma del parametro della funzione esterna e del parametro della funzione interna .

Il trucco è che mentre si restituisce la funzione interna , che fa l'effettiva aggiunta, aviene preservato l'ambito del parametro della funzione esterna ( ). add5 ricorda che il parametro aera 5.

O per mostrare almeno un esempio in qualche modo utile:

  makeTag=function(openTag, closeTag){
     return function(content){
         return openTag +content +closeTag;
     }
 }

 table=makeTag("<table>","</table>")
 tr=makeTag("<tr>", "</tr>");
 td=makeTag("<td>","</td>");
 console.log(table(tr(td("I am a Row"))));

Un altro caso d'uso comune è il cosiddetto IIFE = espressione della funzione immediatamente invocata. È molto comune in javascript falsificare le variabili dei membri privati. Ciò avviene tramite una funzione, che crea un ambito privato = closure, poiché viene richiamata immediatamente dopo la definizione. La struttura è function(){}(). Notare le parentesi ()dopo la definizione. Ciò rende possibile usarlo per la creazione di oggetti con un modello di modulo rivelatore . Il trucco sta nel creare un ambito e restituire un oggetto, che ha accesso a questo ambito dopo l'esecuzione dell'IIFE.

L'esempio di Addi è simile al seguente:

 var myRevealingModule = (function () {

         var privateVar = "Ben Cherry",
             publicVar = "Hey there!";

         function privateFunction() {
             console.log( "Name:" + privateVar );
         }

         function publicSetName( strName ) {
             privateVar = strName;
         }

         function publicGetName() {
             privateFunction();
         }


         // Reveal public pointers to
         // private functions and properties

         return {
             setName: publicSetName,
             greeting: publicVar,
             getName: publicGetName
         };

     })();

 myRevealingModule.setName( "Paul Kinlan" );

L'oggetto restituito ha riferimenti a funzioni (ad esempio publicSetName), che a loro volta hanno accesso a variabili "private" privateVar.

Ma questi sono casi d'uso più speciali per Javascript.

Quale compito specifico potrebbe svolgere un programmatore che potrebbe essere meglio servito da una chiusura?

Ci sono diverse ragioni per questo. Uno potrebbe essere, che è naturale per lui, dal momento che segue un paradigma funzionale . O in Javascript: è pura necessità fare affidamento su chiusure per aggirare alcune stranezze del linguaggio.

Esistono due casi d'uso principali per le chiusure:

1. Asincronia. Supponiamo che tu voglia eseguire un'attività che richiederà del tempo, quindi fare qualcosa al termine. Puoi far aspettare che il tuo codice sia completato, il che blocca ulteriori esecuzioni e può non rispondere al tuo programma, oppure chiamare il tuo compito in modo asincrono e dire "inizia questa lunga attività in background, e quando completa, esegui questa chiusura", dove la chiusura contiene il codice da eseguire al termine.

2. Callback. Questi sono anche noti come "delegati" o "gestori di eventi" a seconda della lingua e della piattaforma. L'idea è che hai un oggetto personalizzabile che, in determinati punti ben definiti, eseguirà un evento , che esegue una chiusura passata dal codice che lo imposta. Ad esempio, nell'interfaccia utente del tuo programma potresti avere un pulsante e assegnargli una chiusura che contiene il codice da eseguire quando l'utente fa clic sul pulsante.

Ci sono molti altri usi per chiusure, ma quelli sono i due principali.

Un paio di altri esempi:

Ordinamento
La maggior parte delle funzioni di ordinamento operano confrontando coppie di oggetti. Sono necessarie alcune tecniche di confronto. Limitare il confronto a un operatore specifico significa un ordinamento piuttosto inflessibile. Un approccio molto migliore consiste nel ricevere una funzione di confronto come argomento della funzione di ordinamento. A volte una funzione di confronto senza stato funziona correttamente (ad esempio, l'ordinamento di un elenco di numeri o nomi), ma cosa succede se il confronto necessita di stato?

Ad esempio, considera di ordinare un elenco di città per distanza in base a una posizione specifica. Una brutta soluzione è quella di memorizzare le coordinate di quella posizione in una variabile globale. Questo rende la funzione di confronto stessa apolide, ma a costo di una variabile globale.

Questo approccio impedisce di disporre di più thread che ordinano contemporaneamente lo stesso elenco di città in base alla loro distanza in due posizioni diverse. Una chiusura che racchiude la posizione risolve questo problema e elimina la necessità di una variabile globale.

Numeri casuali
L'originale rand()non ha preso argomenti. I generatori di numeri pseudocasuali hanno bisogno di stato. Alcuni (ad esempio, Mersenne Twister) hanno bisogno di molto stato. Anche lo stato semplice ma terribile rand()necessario. Leggi un giornale di matematica su un nuovo generatore di numeri casuali e vedrai inevitabilmente variabili globali. È bello per gli sviluppatori della tecnica, non così bello per i chiamanti. Incapsulare quello stato in una struttura e passare la struttura al generatore di numeri casuali è un modo per aggirare il problema dei dati globali. Questo è l'approccio utilizzato in molti linguaggi non OO per far rientrare un generatore di numeri casuali. Una chiusura nasconde lo stato del chiamante. Una chiusura offre la semplice sequenza di chiamata rand()e il rientro dello stato incapsulato.

C'è di più nei numeri casuali di un semplice PRNG. La maggior parte delle persone che vogliono casualità lo vogliono distribuito in un certo modo. Inizierò con numeri estratti casualmente tra 0 e 1, o U (0,1) in breve. Qualsiasi PRNG che genera numeri interi compresi tra 0 e un certo numero massimo lo farà; dividere semplicemente (come un punto mobile) il numero intero casuale per il massimo. Un modo conveniente e generico per implementare questo è creare una chiusura che accetta una chiusura (PRNG) e il massimo come input. Ora abbiamo un generatore casuale generico e facile da usare per U (0,1).

Esistono diverse altre distribuzioni oltre a U (0,1). Ad esempio, una distribuzione normale con una certa media e deviazione standard. Ogni normale algoritmo del generatore di distribuzione che ho incontrato utilizza un generatore U (0,1). Un modo conveniente e generico per creare un generatore normale è quello di creare una chiusura che incapsuli il generatore U (0,1), la media e la deviazione standard come stato. Questa è, almeno concettualmente, una chiusura che prende una chiusura che prende una chiusura come argomento.

Le chiusure equivalgono agli oggetti che implementano un metodo run () e, al contrario, gli oggetti possono essere emulati con chiusure.

• Il vantaggio delle chiusure è che possono essere utilizzate facilmente ovunque ci si aspetti una funzione: ovvero funzioni di ordine superiore, semplici callback (o Pattern di strategia). Non è necessario definire un'interfaccia / classe per creare chiusure ad hoc.

• Il vantaggio degli oggetti è la possibilità di avere interazioni più complesse: più metodi e / o interfacce diverse.

Quindi, l'uso della chiusura o degli oggetti è principalmente una questione di stile. Ecco un esempio di cose che rendono facili le chiusure ma è scomodo da implementare con gli oggetti:

 (let ((seen))
    (defun register-name (name)
       (pushnew name seen :test #'string=))

    (defun all-names ()
       (copy-seq seen))

    (defun reset-name-registry ()
       (setf seen nil)))

Fondamentalmente, incapsuli uno stato nascosto a cui si accede solo attraverso chiusure globali: non è necessario fare riferimento a nessun oggetto, utilizzare solo il protocollo definito dalle tre funzioni.

• Sto estendendo la risposta per rispondere a questo commento da supercat *.

Mi fido del primo commento di Supercat sul fatto che in alcune lingue è possibile controllare con precisione la durata degli oggetti, mentre la stessa cosa non è vera per le chiusure. Nel caso di linguaggi raccolti in modo inutile, tuttavia, la durata degli oggetti è generalmente illimitata ed è quindi possibile costruire una chiusura che potrebbe essere chiamata in un contesto dinamico in cui non dovrebbe essere chiamata (lettura da una chiusura dopo un flusso è chiuso, ad esempio).

Tuttavia, è abbastanza semplice prevenire tale uso improprio catturando una variabile di controllo che proteggerà l'esecuzione di una chiusura. Più precisamente, ecco cosa ho in mente (in Common Lisp):

(defun guarded (function)
  (let ((active t))
    (values (lambda (&rest args)
              (when active
                (apply function args)))
            (lambda ()
              (setf active nil)))))

Qui prendiamo un designatore di funzioni functione restituiamo due chiusure, entrambe catturando una variabile locale denominata active:

• il primo a functioncui activeviene delegato , solo quando è vero
• il secondo è impostato actionsu nilaka false.

Invece (when active ...), è ovviamente possibile avere (assert active)un'espressione, che potrebbe generare un'eccezione nel caso in cui la chiusura venga chiamata quando non dovrebbe esserlo. Inoltre, tieni presente che il codice non sicuro potrebbe già generare un'eccezione da solo se usato male, quindi raramente hai bisogno di un tale wrapper.

Ecco come lo useresti:

(use-package :metabang-bind) ;; for bind

(defun example (obj1 obj2)
  (bind (((:values f f-deactivator)(guarded (lambda () (do-stuff obj1))))
         ((:values g g-deactivator)(guarded (lambda () (do-thing obj2)))))

    ;; ensure the closure are inactive when we exit
    (unwind-protect
         ;; pass closures to other functions
         (progn
           (do-work f)
           (do-work g))

      ;; cleanup code: deactivate closures
      (funcall f-deactivator)
      (funcall g-deactivator))))

Si noti che le chiusure desattivanti potrebbero essere date anche ad altre funzioni; qui, le activevariabili locali non sono condivise tra fe g; inoltre, oltre a active, fsi riferisce solo obj1e gsi riferisce solo a obj2.

L'altro punto menzionato da Supercat è che le chiusure possono portare a perdite di memoria, ma sfortunatamente, è il caso di quasi tutto in ambienti di immondizia. Se sono disponibili, questo può essere risolto da puntatori deboli (la chiusura stessa potrebbe essere mantenuta in memoria, ma non impedisce la garbage collection di altre risorse).

Nulla che non sia già stato detto, ma forse un esempio più semplice.

Ecco un esempio JavaScript che utilizza i timeout:

// Example function that logs something to the browser's console after a given delay
function delayedLog(message, delay) {
  // this function will be called when the timer runs out
  var fire = function () {
    console.log(message); // closure magic!
  };

  // set a timeout that'll call fire() after a delay
  setTimeout(fire, delay);
}

Quello che succede qui è che quando delayedLog()viene chiamato, ritorna immediatamente dopo aver impostato il timeout e il timeout continua a scorrere in background.

Ma quando il timeout scade e chiama la fire()funzione, la console visualizzerà messageciò a cui era stato originariamente passato delayedLog(), perché è ancora disponibile fire()tramite chiusura. Puoi chiamare delayedLog()quanto vuoi, con un messaggio diverso e ritardare ogni volta, e farà la cosa giusta.

Ma immaginiamo che JavaScript non abbia chiusure.

Un modo sarebbe quello di rendere il setTimeout()blocco - più simile a una funzione "sleep" - quindi delayedLog()l'ambito non si spegne fino allo scadere del timeout. Ma bloccare tutto non è molto bello.

Un altro modo sarebbe quello di mettere la messagevariabile in qualche altro ambito che sarà accessibile dopo che delayedLog()l'ambito è andato.

Potresti usare variabili globali - o almeno "più ampie", ma dovresti capire come tenere traccia di quale messaggio va con quale timeout. Ma non può essere solo una coda sequenziale FIFO, perché puoi impostare il ritardo che desideri. Quindi potrebbe essere "first in, third out" o qualcosa del genere. Quindi avresti bisogno di altri mezzi per legare una funzione a tempo alle variabili di cui ha bisogno.

È possibile creare un'istanza di un oggetto timeout che "raggruppa" il timer con il messaggio. Il contesto di un oggetto è più o meno un ambito che rimane. Quindi avresti il ​​timer eseguito nel contesto dell'oggetto, quindi avrebbe accesso al messaggio giusto. Ma dovresti archiviare quell'oggetto perché senza riferimenti verrebbe raccolta spazzatura (senza chiusure, non ci sarebbero riferimenti impliciti ad esso). E dovresti rimuovere l'oggetto una volta sparato il suo timeout, altrimenti rimarrà solo in giro. Quindi avresti bisogno di una sorta di elenco di oggetti di timeout e controllalo periodicamente per gli oggetti "spesi" da rimuovere - o gli oggetti si aggiungerebbero e rimuoveranno dall'elenco e ...

Quindi ... sì, questo sta diventando noioso.

Per fortuna, non è necessario utilizzare un ambito più ampio o contorcersi gli oggetti solo per mantenere determinate variabili. Poiché JavaScript ha delle chiusure, hai già esattamente l'ambito di cui hai bisogno. Un ambito che ti dà accesso alla messagevariabile quando ne hai bisogno. E per questo, puoi cavartela scrivendo delayedLog()come sopra.

PHP può essere usato per aiutare a mostrare un esempio reale in una lingua diversa.

protected function registerRoutes($dic)
{
  $router = $dic['router'];

  $router->map(['GET','OPTIONS'],'/api/users',function($request,$response) use ($dic)
  {
    $controller = $dic['user_api_controller'];
    return $controller->findAllAction($request,$response);
  })->setName('api_users');
}

Quindi sostanzialmente sto registrando una funzione che verrà eseguita per l' URI / api / users . Questa è in realtà una funzione middleware che finisce per essere memorizzata su uno stack. Altre funzioni saranno racchiuse attorno ad esso. Praticamente come fa Node.js / Express.js .

Il contenitore di iniezione delle dipendenze è disponibile (tramite la clausola use) all'interno della funzione quando viene chiamato. È possibile creare una sorta di classe di azioni di instradamento, ma questo codice risulta essere più semplice, rapido e facile da mantenere.

Una chiusura è un pezzo di codice arbitrario, comprese le variabili, che può essere gestito come dati di prima classe.

Un esempio banale è il buon vecchio qsort: è una funzione per ordinare i dati. Devi dargli un puntatore a una funzione che confronta due oggetti. Quindi devi scrivere una funzione. Potrebbe essere necessario parametrizzare tale funzione, il che significa che si assegnano variabili statiche. Ciò significa che non è thread-safe. Sei in DS. Quindi scrivi un'alternativa che richiede una chiusura anziché un puntatore a funzione. Risolvi immediatamente il problema della parametrizzazione perché i parametri diventano parte della chiusura. Rendi il tuo codice più leggibile perché scrivi come gli oggetti vengono confrontati direttamente con il codice che chiama la funzione di ordinamento.

Ci sono tonnellate di situazioni in cui si desidera eseguire alcune azioni che richiedono una buona dose di codice della piastra della caldaia, oltre a un piccolo ma essenziale pezzo di codice che deve essere adattato. Si evita il codice del boilerplate scrivendo una volta una funzione che accetta un parametro di chiusura e fa tutto il codice del boilerplate al suo interno, quindi è possibile chiamare questa funzione e passare il codice per adattarlo come chiusura. Un modo molto compatto e leggibile per scrivere il codice.

Hai una funzione in cui un codice non banale deve essere eseguito in molte situazioni diverse. Questo produceva la duplicazione del codice o il codice contorto in modo che il codice non banale fosse presente una sola volta. Trivial: assegni una chiusura a una variabile e la chiami nel modo più ovvio ovunque sia necessaria.

Multithreading: iOS / MacOS X ha funzioni per fare cose come "eseguire questa chiusura su un thread in background", "... sul thread principale", "... sul thread principale, tra 10 secondi da adesso". Rende banale il multithreading .

Chiamate asincrone: ecco cosa ha visto l'OP. Qualsiasi chiamata che accede a Internet o qualsiasi altra cosa che potrebbe richiedere del tempo (come la lettura delle coordinate GPS) è qualcosa in cui non si può attendere il risultato. Quindi hai funzioni che fanno le cose in background e poi passi una chiusura per dire loro cosa fare quando sono finite.

È un piccolo inizio. Cinque situazioni in cui le chiusure sono rivoluzionarie in termini di produzione di codice compatto, leggibile, affidabile ed efficiente.

Una chiusura è un modo abbreviato di scrivere un metodo in cui deve essere utilizzato. Ti risparmia lo sforzo di dichiarare e scrivere un metodo separato. È utile quando il metodo verrà utilizzato una sola volta e la definizione del metodo è breve. I vantaggi sono ridotti digitando in quanto non è necessario specificare il nome della funzione, il suo tipo di ritorno o il suo modificatore di accesso. Inoltre, quando leggi il codice non devi cercare altrove la definizione del metodo.

Quanto sopra è un riassunto di Comprendi le espressioni lambda di Dan Avidar.

Ciò ha chiarito l'uso delle chiusure per me perché chiarisce le alternative (chiusura vs. metodo) e i vantaggi di ciascuna.

Il seguente codice viene utilizzato una volta e una volta solo durante l'installazione. Scrivendolo sul posto sotto viewDidLoad evita il problema di cercarlo altrove e accorcia le dimensioni del codice.

myPhoton!.getVariable("Temp", completion: { (result:AnyObject!, error:NSError!) -> Void in
  if let e = error {
    self.getTempLabel.text = "Failed reading temp"
  } else {
    if let res = result as? Float {
    self.getTempLabel.text = "Temperature is \(res) degrees"
    }
  }
})

Inoltre, prevede il completamento di un processo asincrono senza bloccare altre parti del programma e una chiusura manterrà un valore da riutilizzare nelle successive chiamate di funzione.

Un'altra chiusura; questo cattura un valore ...

let animals = ["fish", "cat", "chicken", "dog"]
let sortedStrings = animals.sorted({ (one: String, two: String) -> Bool in return one > two
}) println(sortedStrings)