javascript - property - react getters and setters

¿Cuál es el argumento para usar getters y setters de ES6 sobre la convención getProperty/setProperty?

Question

class Foo {
    getName = () => this.name;

    setName = (name) => this.name = name;
}

y

class Foo {
    get name () {
        return this.name;
    }

    set name (name) {
        this.name = name;
    }
}

Puedo pensar en varios ejemplos donde los captadores de ES6 están en desventaja , por ejemplo

No puede escribir un captador que devolverá un valor basado en un valor de parámetro:

/**
 * Returns an instance of Card associated with an element.
 *
 * @param {HTMLElement} element
 * @return {Card|undefined}
 */
getCard = (element) => {
    return _.find(this.index, {
        element: element
    });
};

Eso está bien, sin embargo, si usa esto y ES6, está introduciendo una inconsistencia de estilo de código.

No puede distinguir entre un acceso directo a la propiedad y el acceso a un método.

class Foo {
    get name () {
        return this.name;
    }

    get expensive () {
        // An operation that takes a lot of computational power.
    }

    get randomValue () {
        // Returns random value.
    }
}

let foo = Foo();

foo.name;
foo.expensive;
foo.randomValue;

La desventaja es que no es intuitivo que una propiedad a la que está accediendo requiera un gran poder de cómputo (y, por lo tanto, debe ser memorizado) o que cambie cada vez que acceda a ella.

Finalmente, los getters / setters no funcionan con las funciones de flecha . Ejemplo inválido:

class Foo {
    get name = () => {
        return this.name;
    }

    set name = (name) => {
        this.name = name;
    }
}

Lo que los expone a los problemas de contexto.

¿Cuál es la ventaja de usar getters y setters de ES6 sobre la extracción convencional de get{PropertyName} y set{PropertyName} ?

Answer 1

No puede distinguir entre un acceso directo a la propiedad y el acceso a un método.

Este es el principal argumento a su favor.

Uno de los mayores y extraños inconvenientes de escribir el código OO clásico de estilo Java es que cualquier objeto con una propiedad expuesta debe tener captadores y decodificadores escritos, y una gran cantidad de texto repetitivo sale de esto, especialmente para una gran estructura de datos. tipo de objetos (por ejemplo, DTO ).

El razonamiento de todo esto es que no se pueden simplemente hacer públicas las propiedades, porque de lo contrario no se les puede agregar lógica sin romper la API (por ejemplo, la lógica solo permite configurar ciertos valores, o refactorizar y almacenar una propiedad en una forma ligeramente diferente al mismo tiempo que se expone la misma API externa, o similar). Consulte https://softwareengineering.stackexchange.com/questions/176876/why-shouldnt-i-be-using-public-variables-in-my-java-class para obtener algunos argumentos típicos al respecto.

Creo que podría decir cómodamente que esto se ha llevado a su extremo lógico en los últimos años, pero eso no significa que esté mal; al exponer un campo público para acceso directo, de hecho está exponiendo la implementación interna de cómo está almacenando esos datos, y eso significa que ya no puede cambiarlo de manera fácil o segura.

Los getters / setters de ES6 solucionan esto. El hecho de que algo sea legible como propiedad directa de un objeto ya no le dice nada acerca de la implementación de esa propiedad. Podría haber sido un campo originalmente, pero recientemente se convirtió en un acceso de propiedad de ES6, sin que la API cambiara. La implementación de la propiedad está oculta del resto de su base de código y, por lo tanto, es más fácil de modificar.

La desventaja es que no es intuitivo que una propiedad a la que está accediendo requiera un gran poder de cómputo (y, por lo tanto, debe ser memorizado) o que cambie cada vez que acceda a ella.

Tienes razón, este es un riesgo. Eso también es un problema con cualquier getX (); Existe una fuerte convención que sugiere que los métodos sencillos y agradables como ''getName ()'' nunca deberían estar haciendo cosas costosas entre bastidores, incluso si son métodos, y si rompes eso, casi seguro terminarás atrapando gente (incluyendo usted mismo, dentro de 6 meses)

Mudarse a propiedades no cambia esto, pero tiene razón en que ES6 significa que ya no se garantiza que sea seguro para accesos a propiedades simples. La respuesta es simplemente asegurarse de que usted (y todos los demás) se apeguen a la convención y Principio de asombro mínimo : como con los getters y setters de apariencia simple, los usuarios de ES6 deberían hacer cosas sencillas y baratas, y no deberían ser extraños. efectos secundarios en otros lugares.

Answer 2

No hay cosas específicas que no puedas hacer con getMethod() y setMethod() , pero permite diferentes estilos de código. Por ejemplo, podrías, con un get foo y set foo , escribir:

obj.foo++;

que llamaría al getter y luego al setter. Por supuesto, podría hacer que la función set valide que el valor está dentro de un rango específico, por ejemplo. El código tradicional se vería así:

obj.setFoo(obj.getFoo() + 1);

No puede distinguir entre un acceso directo a la propiedad y el acceso a un método.

Ese es el punto. Yo diría que si algo es realmente costoso, simplemente no debería usar getters para eso.