lista - ¿Por qué evitar crear objetos en JavaScript?

recorrer array de objetos javascript

Question

Estoy siguiendo un tutorial de JavaScript en W3Schools. Mientras leen casi en cada página, le dan una nota al usuario para que "Evite la creación de objetos" y, en su lugar, utilice tipos de datos primitivos. Dan razones para esto ya que "el código se vuelve difícil de entender o la velocidad de ejecución se reducirá si se usan objetos". ¿Es cierto que deberíamos evitar crear objetos en JavaScript?

Por ejemplo:

var value = new Number(1); // Avoid this
var value = 1; // do something like this instead.

Answer 1

Cambia la forma intuitiva en que los operadores se comportan con números, cadenas y booleanos:

• la comparación estricta ( === ) se rompe cuando se construye cualquiera de los números, por lo que 42 === 42 es verdadero, mientras que 42 === new Number(42) no lo es,
• la comparación abstracta ( == ) se rompe cuando ambos números son objetos, por lo que 42 == new Number(42) es verdadero, mientras que el new Number(42) == new Number(42) no es,
• el operador typeof da resultados diferentes cuando se construye un número, por lo que typeof(42) es number , pero typeof(new Number(42)) es object ,
• cuando se convierte a booleano, 0 es falso, pero el new Number(0) es verdadero, por lo que los siguientes dos tendrán un comportamiento diferente:

var a = 0;
if (a)
console.log("not zero");
else
console.log("zero!"); // "zero!"
var b = new Number(0);
if (b)
console.log("not zero"); // "not zero"
else
console.log("zero!");

Por lo tanto, evite el new Number , la new String y el new Boolean .

Aparte de eso, está el problema de usar / no usar new con los constructores. Se deriva de varios hechos:

• en JS, un constructor es una función regular, que utiliza this.foo sintaxis para agregar nuevas propiedades y métodos;
• cuando se invoca sin la new palabra clave, se convierte en el objeto global, lo que genera efectos secundarios.

Como resultado, un pequeño error puede tener efectos catastróficos:

color = "blue";
var Fruit = function(color) {
this.color = color;
return this;
};
var apple = new Fruit("green");
console.log(apple.color); // "green" -- okay
console.log(color); // "blue" -- okay
var banana = Fruit("yellow");
console.log(banana.color); // "yellow" -- okay
console.log(color); // "yellow" -- wait, what?
console.log(banana.apple); // "{ color: ''green'' }" -- what??
console.log(banana.document); // "{ location: [Getter/Setter] }" -- what???

(Es por eso que algunas personas recurren a agregar comprobaciones explícitas en el constructor o usar cierres en su lugar. Pero eso es para otra historia).

Answer 2

La frase "evitar la creación de objetos" por sí misma es absurda en JavaScript, que tiene objetos en todas partes y es uno de los lenguajes más orientados a objetos que existen. Pero "evitar la creación de versiones de objetos primitivos", que es lo que hace el código que cita, es válido. Es decir, evite new String new Number , new Number new Boolean y new Boolean .

JavaScript tiene versiones primitivas y de objetos de cadenas, números y booleanos. Casi nunca hay ninguna razón para crear la versión de objeto de ninguno de ellos explícitamente, y hacerlo puede conducir a confusión; ver comentarios en línea:

var s1, s2, n1, n2;
// These are false because with ===, an object is never equal to a non-object
s1 = new String("hi");
s2 = "hi";
console.log(s1 === s2); // false
n1 = new Number(42);
n2 = 42;
console.log(n1 === n2); // also false
// These are false because even with ==, two *different* objects are never equal
// (even if they''re equivalent)
s1 = new String("what the...");
s2 = new String("what the...");
console.log(s1 == s2); // also false
n1 = new Number(42);
n2 = new Number(42);
console.log(n1 == n2); // also false

Las versiones de objeto de cadenas, números y booleanos existen ampliamente para permitir que se proporcionen métodos en primitivas utilizando el mismo mecanismo que proporciona métodos para tipos de objeto. Cuando tu lo hagas

console.log("foo".toUpperCase()); // "FOO"

se crea un objeto temporal para la cadena primitiva "foo" y luego se lee la propiedad toUpperCase de ese objeto. Como el objeto hereda de String.prototype , tiene toUpperCase y todo está bien. Una vez que se finaliza la operación, el objeto temporal se descarta (a menos que algo lo mantenga como referencia, pero nada lo hace y nada puede hacerlo con toUpperCase , tendría que agregar un método a String.prototype que devolvió el objeto para que para mantenerse cerca).