2010-07-10 18 views
5

Como programador de C#, tengo la costumbre de hacer las cosas en privado que pueden y deben ser privadas, y siempre me da una sensación extraña cuando un tipo JS me expone todas sus partes privadas (y esa sensación no es ' excitado '). Supongamos que tengo un tipo que tiene un método draw, que internamente llama a drawBackground y drawForeground, lo que no tiene sentido que lo llamen por su cuenta. ¿Cómo debo implementar esto?Javascript: ¿debería estar ocultando mis implementaciones?

Opción 1

Foo = function(){ 
    this.draw(); 
}; 

Foo.prototype.draw = function(){ 
    this.drawBackground(); 
    this.drawForeground(); 
}; 

Foo.prototype.drawBackground = function(){}; 
Foo.prototype.drawForeground = function(){}; 

Opción 2

Foo = (function(){ 

    var constructor = function(){ 
    this.draw(); 
    }; 

    var drawBackground = function(){}; 
    var drawForeground = function(){}; 

    constructor.prototype.draw = function(){ 
    drawBackground.call(this); 
    drawForeground.call(this); 
    }; 

    return constructor; 

})(); 

La diferencia, por supuesto, es que en el primer ejemplo, los métodos drawBackground y drawForeground son parte de la API pública , mientras que están ocultos al exterior en el segundo. ¿Es eso deseable? ¿Cuál debería preferir? ¿Me equivoco al aplicar mis hábitos de C# a Javascript y debería hacer todo extensible y anular en JavaScript? ¿Y cuáles son las implicaciones de rendimiento del .call(this)?

+0

Probablemente misundertood su pregunta, pero en la Opción 1 el drawBackground/drawForeground son públicos (incluso si desea que sean privados) por lo que para lograr lo que quiere solo funciona la Opción 2. –

+0

Bueno, sí, esa es mi pregunta, ¿debería preferir hacer las cosas de manera privada cuando puedo? – JulianR

Respuesta

7

Hay una cita muy conocida entre los desarrolladores de Perl que proviene de la (in) famoso libro Camel: "Un módulo Perl preferiría que permanecer fuera de su sala de estar, ya que no fueron invitados, no porque tenga una escopeta . ". La filosofía es que si usted, como desarrollador de una biblioteca, desea distinguir entre su API pública y privada, eso es genial. Haz eso y documentalo. Quien llama a su código debe saber cuál es cuál, pero también ser libre de actuar como un idiota si lo decide y llamar a cosas que no cree que deberían llamar. A partir de un fondo OO, eso es herético, pero con lenguajes de scripting, así es como funcionan.

La respuesta a esto es un poco subjetiva, pero les diré que cuando estoy escribiendo JavaScript y tengo métodos o variables que serían privados si estuviera codificando en .NET, simplemente los prefijo con algo así como "prv_" o "p_" o simplemente "_" ... lo que sea que flote su bote. De esa forma, les ha dicho a sus usuarios que estas cosas deben ser privadas y podrían cambiar por debajo de ellas. Y de esa manera, si eligen llamar a sus métodos privados de todos modos, ese código dudoso sobresaldrá como un pulgar dolorido.

+1

Sí, lo veo mucho en frameworks como ExtJS, donde las cosas se han marcado como '// private' a pesar de que son perfectamente accesibles. – JulianR

+0

Prefijo con _ parece ser la práctica más comúnmente utilizada entre las bibliotecas. Algunos también usan un comentario o una anotación @ JSdoc privada. –

Cuestiones relacionadas