2012-07-16 16 views
8

He revisado todas las otras (excelentes) respuestas en SO (especialmente esto: How do JavaScript closures work?) pero quería su opinión sobre mi comprensión del concepto.¿Es este un caso de uso válido para el cierre de JavaScript?

Entiendo que un caso de uso es ocultar la implementación de métodos privados del acceso público.

El otro que lo pienso es tener como un generador de fábrica:

<script> 

function carFactory(make) { 

    var m = make; 
    return { manufacture: function (model) 

     {console.log("A " + m + " " + model + " has been created");} 

    } 
} 

toyotaFactory = carFactory("toyota"); 
hondaFactory = carFactory("honda"); 

toyotaFactory.manufacture("corolla"); 
toyotaFactory.manufacture("corolla"); 
hondaFactory.manufacture("civic"); 

</script> 

Este salidas:

A toyota corolla has been create 
A toyota corolla has been created 
A honda civic has been created 

Así que crees que es un caso de uso válido para el cierre (es decir, la creación de fábricas múltiples que usan la misma base de código)? ¿O puedo lograr lo mismo usando algo mucho mejor?

Tenga en cuenta que la pregunta es menos sobre la implementación técnica de cierres y más sobre casos de uso válidos en el diseño/desarrollo de aplicaciones.

Gracias.

+0

Me parece bien. – Almo

+0

¡Se ve bien! No veo nada de malo en eso. – Linuxios

+3

Técnicamente, no necesita 'm' - simplemente puede usar' make' directamente. – josh3736

Respuesta

0

cierres son extremadamente poderosa construcción, con una gran cantidad de usos útiles. El que usaste allí es realmente una especie de "truco". El uso más común para cierres, es cuando ha implementado alguna funcionalidad que "hace algo" en el medio ... Y ese "hace algo" puede configurarse para más o menos lo que quiera ... Por ejemplo, la funcionalidad jQuery ajax puede "hacer algo" cuando la solicitud tiene un error, o cuando tuvo éxito, etc ... Si no tenía cierres, solo podría pasar una función "estáticamente definida", que probablemente necesite reúna el contexto necesario para hacer lo que quiera que haga desde variables globales, o tendrá que usar la misma firma para todas las funciones, como lo que se hace en C o C++ como función (datos personalizados) {} ... Cierres permite a "crear dinámicamente funciones" en tiempo de ejecución, reteniendo el contexto que tienen cuando se crearon, para que pueda pasar a los módulos que necesitan "hacer algo" casi de cualquier manera que desee, de una manera realmente fácil (en contrato con lo lo harías en c o C++ o sin closu res, que es feo, propenso a errores, y un truco también).

Así que cada vez que hay que "configurar" funcionalidad personalizada dentro de algo, va a utilizar un cierre ...

1

Si estoy entendiendo bien su pregunta, no tienen que ver con el mantenimiento de la propiedad privada make ? Si ese es el caso, entonces un cierre no es realmente necesario, y se podía conseguir la misma funcionalidad utilizando un prototipo ...

function carFactory(model){ 
    this.m = make; 
} 

carFactory.prototype.manufacture = function(model){ 
    console.log('A ' + this.m + ' ' + model + ' has been created'); 
} 

Cuál ha asociado ventajas de rendimiento (reducción de la memoria y el aumento de la velocidad), según this question .

+1

Esto almacena el nombre del modelo, pero no lo mantiene privado. Las variables de miembros están disponibles para cualquiera.La ventaja del cierre del OP es que el nombre del modelo es verdaderamente privado. – jfriend00

+0

sí, edité mi respuesta para ser un poco más específico. esta es solo una respuesta factible si mantener 'make' private es innecesario. si lo es, sin embargo, un cierre es la mejor solución. – market

+1

Pensé que el objetivo del cierre en la pregunta del OP era la privacidad. Estoy de acuerdo en que si no se necesita privacidad, entonces el cierre es más complicado (y probablemente sea un consumo de memoria peor) de lo necesario. Si es público, una variable miembro es la más directa. – jfriend00