¿Cuáles son las ventajas de los métodos individuales combinados "Getter / Setter VS"?

12

Esto es lo que yo llamo un método "combinado" de getter / setter (de jQuery):

var foo = $("<div>This is my HTML</div>"),
    myText;

myText = foo.text(); // myHTML now equals "This is my HTML" (Getter)
foo.text("This is a new value"); // The text now equals "This is a new value")

Esta es la misma lógica con métodos separados (teóricos):

var foo = $("<div>This is my HTML</div>"),
    myText;

myText = foo.getText(); // myHTML now equals "This is my HTML" (Getter)
foo.setText("This is a new value"); // The text now equals "This is a new value")

Mi pregunta:

Al diseñar una biblioteca como jQuery, ¿por qué decidirías ir a la primera ruta y no a la segunda? ¿No es el segundo enfoque más claro y fácil de entender de un vistazo?

    
pregunta Levi Hackwith 11.01.2013 - 17:03

4 respuestas

13

Aquí simplemente especulaba, pero me gustaría creer que los desarrolladores de jQuery que usaron gran parte del estilo funcional en la estructuración de jQuery claramente tienen una inclinación hacia el paradigma funcional.

Dado que, en el paradigma funcional, existe una fuerte cultura de reducción de la redundancia, y podría argumentarse que el segundo enfoque tiene redundancia innecesaria. El primer enfoque puede no ser claro para alguien acostumbrado a todos los lenguajes imperativos comunes, pero indudablemente está haciendo más con menos al tener solo un método en lugar de dos. Esto puede ser peligroso, pero es una herramienta común en el paradigma funcional y algo a lo que uno se acostumbra rápidamente.

Practica en el paradigma funcional y rápidamente superas ese deseo hacia la ceremonia y aprendes a apreciar la capacidad de hacer más con menos. Aunque esto es reconocible, es una elección subjetiva basada en la preferencia de la misma manera que muchas personas tienen preferencias con respecto a la gestión de espacios en blanco. De esta manera, no digo que una manera sea mejor, sino que son cosas a las que la gente se acostumbra, y probablemente por eso jQuery tiene el enfoque que tiene.

Esta sería la razón por la que creo que los desarrolladores de jQuery hicieron esto y, en general, por qué alguien podría adoptar este enfoque.

    
respondido por el Jimmy Hoffa 11.01.2013 - 17:13
2

El formulario

foo.text("This is a new value"); 

puede implicar una serie de cosas. Más comúnmente, sugiere un objeto foo , con un método llamado text aceptando una cadena, que hace algo . No hay ninguna implicación de que esto sea una propiedad en absoluto.

En muchos idiomas, esto puede considerarse una forma abreviada de

var result = foo.text("This is a new value"); 

donde se descarta el resultado. Por lo tanto, este enfoque es demasiado ambiguo como para ser una forma efectiva de establecer una propiedad (desde el punto de vista de la legibilidad del código).

    
respondido por el Robert Harvey 11.01.2013 - 17:26
1

Es un poco especulativo, pero aquí está mi oportunidad.

jQuery abarca completamente la naturaleza funcional de javascript. Eso es lo que lo hace tan impresionante, pero puede dejar a muchos desarrolladores rascándose la cabeza cuando provienen de un lenguaje OO más puro, como Java. Parece romper todas las convenciones y buenas prácticas.

El lenguaje funcional tiende a poner el énfasis en una sintaxis declarativa. Tienden a leer como declaración de un hecho en lugar de como comandos. Ejemplo

var eligible = customers.where(c => c.age > 30);

que puede leerse como "el cliente elegible es el cliente cuya edad es mayor de 30 años". Por contraposición, el lenguaje imperativo se lee como una secuencia de comando

for (customer in customers)
    if (customer.age > 30)
        eligible.add(customer)

Se puede leer como "Verifique cada cliente, y si su edad es mayor de 30 años, agréguelos a la colección elegible"

Agregar una operación set y get haría que jQuery se sintiera como una biblioteca imperativa. Puede contrarrestar la forma de leer las siguientes declaraciones

// The element tag have an html of <p>hello</p>
$("#element").html("<p>hello</p>"); 

// content represent the html of the element tag
var content = $("#element").html();


//Imperative style

// Set the element tag to an inner html of <p>hello</p>
$("#element").setHtml("<p>hello</p>");

//Get the html of #element, and put it in the content variable
var content = $("#element").getHtml();

Al mantener el verbo de acciones fuera de la jiuery api, lo hicieron sentir como una API declarativa. Da una sensación consistente y funcional a la biblioteca. Por eso creo que sobrecargaron las palabras clave.

    
respondido por el Laurent Bourgault-Roy 11.01.2013 - 17:53
1

Hace que se comporte algo más como properties , que solo se introdujeron recientemente en JavaScript, y por lo tanto aún no se utilizan ampliamente, especialmente en bibliotecas como jQuery que están destinadas a ayudar a abstraer las incompatibilidades del navegador.

Si alguna vez ha visto una definición de clase llena de tales propiedades, los prefijos "set" y "get" parecen superfluos, porque la adición del parámetro de valor ya le dice que es un setter. Martin Fowler hace un buen punto sobre los captadores que requieren un parámetro, pero incluso en ese contexto, el parámetro de valor adicional claramente indica un setter, así como el hecho de que rara vez aparece un setter en el lado derecho de una tarea. Y cuando esté escribiendo el código, debe consultar la documentación de la biblioteca de todos modos.

Como solo pediste ventajas, no cubriré las desventajas.

    
respondido por el Karl Bielefeldt 11.01.2013 - 18:02

Lea otras preguntas en las etiquetas