@marco.r
Grazie delle spiegazioni, alcuni punti che hai messo in luce mi stanno aiutando a comprendere, anche se non ho ancora capito se un bravo programmatore ad oggetti, uno che ha appreso best practices e design patterns e li sa applicare quando, dove e come serve, ne abbia realmente bisogno (per esempio rispetto al fatto che con le closure hai la possibilità di migliorare la località)
Quote:
Originariamente inviato da marco.r
Un uso molto importante e' quello della gestione delle risorse. Vista la presenza del garbage collection, in Java in generale non sappiamo quando viene deallocato un oggetto e se a questo oggetto e' associato una risorsa "esterna" (collegamento a db, file, etc.) dobbiamo liberare la risorsa associata a mano oppure rischiare di esaurirle. Se pero' posso passare un pezzo di codice, allora posso scrivere una funzione/metodo che prende ad esempio il nome del file e il codice da eseguire, apre il file, esegue il pezzo di codice, e si preoccupa della pulizia non appena il codice e' stato eseguito.
|
Sì perfetto, ma nel talk di J. Block ci si indirizza alla soluzione dello stesso problema in un altro modo: intoduci un nuovo costrutto da usarsi al posto del tradizionale try{}cacth(Exception e){}finally{} quando hai a che fare con le risorse, per sempio con un semplice try{} che implicitamente chiude correttamente la risorsa quando si esce dal suo scope.
Molto semplice, e conciso, direi.