reveal patterns pattern patrones example diseño javascript design-patterns coding-style

patterns - Javascript: patrón de configuración



reveal pattern javascript (3)

Las funciones de JavaScript están firmadas solo por su nombre.

Por lo tanto, puedes hacer:

function kick(x, reason, amount) { if(reason && amount) { // do stuff with x as person, reason and amount } else if(x) { // do stuff with x as config } else { // do stuff with no parameters } }

Otra solución es usar la variable arguments, que es una matriz que contiene todos los parámetros que pasaron a una función en javascript.

function kick() { alert(arguments.length); }

Problema : una función de Javascript necesita pocos parámetros para trabajar:

function kick(person, reason, amount) { // kick the *person* with the *amount*, based on the *reason* }

Como no hay forma de sobrecargar la función en JS, como lo hace en Java , si debe diseñarse para una fácil mejora futura (adición de parámetros), se puede escribir como:

/* Function Parameters pattern */ function kick() { // kick the person as in *arguments[0]*, with the amount as in *arguments[1]*, // based on the reason as in *arguments[2]*, with the strength as in *arguments[3]* }

o

/* Object Configuration Pattern */ function kick(config) { // kick the person as in *config.person*, with the amount as in *config.amount*, // based on the reason as in *config.reason*, with the strength as in *config.strength* }

Sé que el Patrón de configuración de objetos permite el aumento de las propiedades predeterminadas .

Entonces, la pregunta es: si no necesito aumentar ninguna propiedad con los parámetros, ¿hay alguna razón importante para usar cualquiera de las soluciones propuestas en oposición a la otra?


No tienes que ir estrictamente con ninguno de los tres. Si observa cómo lo hace jQuery, examina el tipo y la cantidad y la posición de los parámetros para determinar qué sabor sobrecargado de la función se está utilizando.

Supongamos que tiene tres sabores de kick() , uno que toma persona, razón y cantidad, y uno que toma solo persona con razón y cantidad obteniendo valores predeterminados y otro que toma un objeto de configuración con al menos una persona en él. Puedes ver dinámicamente cuál de las tres opciones tienes así:

function kick(person, reason, amount) { if (person.person) { // must be an object as the first parameter // extract the function parameters from that object amount = person.amount; reason = person.reason; } amount = amount || 5; // apply default value if parameter wasn''t passed reason = reason || "dislike"; // apply default value if parameter wasn''t passed // now you have person, reason and amount and can do normal processing // you could have other parameters too // you just have to be to tell which parameter is which by type and position // process the kick here using person, reason and amount }


Usar un objeto tiene algunas ventajas:

1. El código es más legible

Considere las siguientes dos llamadas:

kick({user: u, reason: "flood", log: true, rejoin: false, timeout: 60000, privmessage: true}); kick(u, "flood", true, false, 60000, true);

e imagina a alguien más leyendo la llamada. ¿Cuál es la primera true ? Tenga en cuenta también que usted mismo en unos pocos meses estaría en la misma posición exacta (no recordar cuál es el cuarto parámetro para kick es muy similar a no saberlo).

2. Puedes tunear parámetros

Con el enfoque de objeto puede pasar una función un conjunto de parámetros que esta función debe usar para llamar a otra función

function kickgroup(users, parms) { for (var i=0; i<users.lenght; i++) { var uparms = Object.create(parms); uparms.user = users[i]; kick(uparms); } }

Tenga en cuenta también que en el caso de arguments no es necesario que se castigue utilizando la sintaxis de arguments[x] . Puede declarar los parámetros y agregarlos a medida que la función evoluciona: cualquier parámetro que no se haya pasado se configurará como undefined (y si lo necesita, puede acceder a arguments.length para distinguir si el llamador pasó explícitamente su función undefined ).