¿Qué problemas de programación comunes se resuelven mejor mediante el uso de prototipos y cierres?

Por mucho que entiendo ambos conceptos, no puedo ver cómo puedo aprovechar los cierres y prototipos de JavaScript, aparte de usarlos para crear bloques de clase instantaneos y / o encapsulados (lo que me parece más una solución que un activo) )

Es mucho más fácil enamorarse de otras características de JS, como las funciones como valores o la evaluación lógica de los no booleanos ...

¿Qué problemas de programación comunes se resuelven mejor mediante el uso de herencias y cierres propotípicos?

1. Los cierres son los que hacen que las funciones como valores sean útiles. Cuando pasa la función, es casi seguro que la necesita para tomar algún contexto. Que es exactamente lo que hacen los cierres.

2. Los prototipos son solo una versión más simple de la herencia de clases. En lugar de tener instancias y clases (representadas por tipos especiales de instancias en lenguajes dinámicos de todos modos), solo tiene instancias y el prototipo es la clase (y su prototipo es la clase base). Entonces, básicamente resuelven los mismos problemas, solo los prototipos son más fáciles de implementar (es por eso que JavaScript los eligió), algo más difíciles de usar (bueno, simplemente falta de azúcar sintáctico) y para mejor o peor, más fáciles de abusar.

Los cierres no resuelven ningún problema de programación que no se pueda resolver sin ellos. Sin embargo, esto se puede decir para cualquier característica del lenguaje que no sea necesaria para la integridad de Turing, por lo que no significa mucho.

Piense en cómo debe reescribir cualquier código que use un cierre, para no usar un cierre. Probablemente le otorgaría a la función propiedades de cierre adicionales para que pueda mantener su estado entre llamadas. Lo cual sería simplemente copiar las variables que ya están dentro del alcance en propiedades del mismo nombre en la función, por lo que sería el tipo de ejercicio de escritura sin sentido que hace que quieras gritar en la pantalla "¿por qué no puede el estúpido compilador ( intérprete, lo que sea) resolver esto? Eso es lo que son los cierres, el estúpido compilador es lo suficientemente inteligente como para descubrirlo.

Los cierres son geniales para la lógica asincrónica.

Se trata principalmente de la organización del código para mí. Tener un montón de funciones locales para dividir lo que está haciendo el código es bueno.

create: function _create(post, cb) {
    // cache the object reference
    var that = this;

    function handleAll(err, data) {
        var rows = data.rows;

        var id = rows.reduce(function(memo, item) {
            var id = +item.id.split(":")[1];
            return id > memo ? id : memo;
        }, 0);
        id++;


        var obj = {
            title: post.title,
            content: post.content,
            id: id,
            // refer to the object through the closure
            _id: that.prefix + id,
            datetime: Date.now(),
            type: "post"
        }

        PostModel.insert(obj, handleInsert);
    }

    // this function doesn't use the closure at all.
    function handleInsert(err, post) {
        PostModel.get(post.id, handleGet);
    }

    // this function references cb and that from the closure
    function handleGet(err, post) {
        cb(null, that.make(post));
    }

    PostModel.all(handleAll);
}

Aquí hay otro ejemplo de cierre

var cachedRead = (function() {
    // bind cache variable to the readFile function
    var cache = {};

    function readFile(name, cb) {
        // reference cache
        var file = cache[name];
        if (file) {
            return cb(null, file);
        }

        fs.readFile(name, function(err, file) {
            if (file) cache[name] = file;
            cb.apply(this, arguments);
        });
    }

    return readFile;
})();

Y otro ejemplo

create: function _create(uri, cb, sync) {
    // close over count
    var count = 3;

    // next only fires cb if called three times
    function next() {
        count--;
        // close over cb
        count === 0 && cb(null);
    }

    // close over cb and next
    function errorHandler(err, func) {
        err ? cb(err) : next();
    }

    // close over cb and next
    function swallowFileDoesNotExist(err, func) {
        if (err && err.message.indexOf("No such file") === -1) {
            return cb(err);
        }
        next();
    }

    this.createJavaScript(uri, swallowFileDoesNotExist, sync)

    this.createDocumentFragment(uri, errorHandler, sync);

    this.createCSS(uri, swallowFileDoesNotExist, sync);
},

La alternativa al uso de cierres es curvar variables en funciones usando f.bind(null, curriedVariable).

Sin embargo, en general, la lógica de programación asincrónica utiliza devoluciones de llamada y el estado de manipulación en las devoluciones de llamada depende del currículum o los cierres. Personalmente prefiero los cierres.

En cuanto a los usos de la herencia prototípica, ¿permite OO? ¿La herencia prototípica realmente necesita hacer más que eso para que se considere "útil"? Es una herramienta de herencia, permite la herencia, eso es lo suficientemente útil.