¿Por qué usar getters y setters / accessors?

¿Cuál es la ventaja de usar getters y setters, que solo obtienen y establecen, en lugar de simplemente usar campos públicos para esas variables?

Si getters y setters están haciendo algo más que el simple get / set, puedo resolver esto muy rápido, pero no estoy 100% claro sobre cómo:

public String foo;

es peor que:

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

Mientras que el primero toma mucho menos código repetitivo.

En realidad, hay muchas buenas razones para considerar el uso de accesores en lugar de exponer directamente los campos de una clase, más allá del argumento de encapsulación y facilitar los cambios futuros.

Estas son algunas de las razones que conozco:

• Encapsulación del comportamiento asociado con la obtención o configuración de la propiedad: esto permite agregar funcionalidades adicionales (como la validación) más fácilmente más adelante.
• Ocultar la representación interna de la propiedad mientras expone una propiedad utilizando una representación alternativa.
• Aislar su interfaz pública del cambio, permitiendo que la interfaz pública permanezca constante mientras la implementación cambia sin afectar a los consumidores existentes.
• Controlar la semántica de la vida útil y la gestión de la memoria (eliminación) de la propiedad, particularmente importante en entornos de memoria no gestionados (como C ++ u Objective-C).
• Proporcionar un punto de intercepción de depuración para cuando una propiedad cambia en tiempo de ejecución; depurar cuándo y dónde una propiedad cambia a un valor particular puede ser bastante difícil sin esto en algunos idiomas.
• Interoperabilidad mejorada con bibliotecas que están diseñadas para operar contra captadores / establecedores de propiedades: burlas, serialización y WPF vienen a la mente.
• Permitir que los herederos cambien la semántica de cómo se comporta y se expone la propiedad anulando los métodos getter / setter.
• Permitir que el getter / setter se pase como expresiones lambda en lugar de valores.
• Los getters y setters pueden permitir diferentes niveles de acceso; por ejemplo, get puede ser público, pero el conjunto podría estar protegido.

Debido a que dentro de 2 semanas (meses, años) a partir de ahora, cuando se dé cuenta de que su setter necesita hacer más que solo establecer el valor, también se dará cuenta de que la propiedad se ha utilizado directamente en otras 238 clases :-)

Un campo público no es peor que un par getter / setter que no hace nada más que devolver el campo y asignarlo. Primero, está claro que (en la mayoría de los idiomas) no hay diferencia funcional. Cualquier diferencia debe estar en otros factores, como la capacidad de mantenimiento o la legibilidad.

Una ventaja a menudo mencionada de los pares getter / setter, no lo es. Existe la afirmación de que puede cambiar la implementación y sus clientes no tienen que ser recompilados. Supuestamente, los configuradores le permiten agregar funcionalidades como validación más adelante y sus clientes ni siquiera necesitan saberlo. Sin embargo, agregar validación a un colocador es un cambio en sus condiciones previas, una violación del contrato anterior , que era, simplemente, "puede poner cualquier cosa aquí, y puede obtener lo mismo más tarde del getter".

Entonces, ahora que rompió el contrato, cambiar todos los archivos en la base de código es algo que debe hacer, no evitar. Si lo evita, está asumiendo que todo el código asumió que el contrato para esos métodos era diferente.

Si ese no hubiera sido el contrato, entonces la interfaz estaba permitiendo a los clientes poner el objeto en estados no válidos. Eso es exactamente lo opuesto a la encapsulación. Si ese campo no se pudo establecer realmente desde el principio, ¿por qué no se realizó la validación desde el principio?

Este mismo argumento se aplica a otras supuestas ventajas de estos pares getter / setter de transferencia: si luego decide cambiar el valor establecido, está rompiendo el contrato. Si anula la funcionalidad predeterminada en una clase derivada, de una manera más allá de algunas modificaciones inofensivas (como el registro u otro comportamiento no observable), está rompiendo el contrato de la clase base. Esa es una violación del Principio de sustituibilidad de Liskov, que se considera uno de los principios de OO.

Si una clase tiene estos captadores y establecedores tontos para cada campo, entonces es una clase que no tiene invariantes, ni contrato . ¿Es realmente un diseño orientado a objetos? Si toda la clase tiene esos captadores y establecedores, es solo un titular de datos tonto, y los titulares de datos tontos deberían verse como titulares de datos tontos:

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

Agregar pares getter / setter de paso a dicha clase no agrega valor. Otras clases deberían proporcionar operaciones significativas, no solo operaciones que los campos ya proporcionan. Así es como puedes definir y mantener invariantes útiles.

Cliente : "¿Qué puedo hacer con un objeto de esta clase?"
Diseñador : "Puedes leer y escribir varias variables".
Cliente : "Oh ... genial, supongo?"

Hay razones para usar getters y setters, pero si esas razones no existen, hacer pares getter / setter en nombre de dioses de encapsulación falsa no es algo bueno. Las razones válidas para hacer captadores o establecedores incluyen las cosas que a menudo se mencionan como los posibles cambios que puede realizar más adelante, como la validación o diferentes representaciones internas. O tal vez el valor debería ser legible por los clientes pero no escribible (por ejemplo, leer el tamaño de un diccionario), por lo que un simple captador es una buena opción. Pero esas razones deberían estar ahí cuando elijas, y no solo como algo potencial que podrías desear más adelante. Esta es una instancia de YAGNI ( No lo vas a necesitar ).

Mucha gente habla de las ventajas de los captadores y setters, pero quiero jugar al abogado del diablo. En este momento estoy depurando un programa muy grande en el que los programadores decidieron hacer que todo sea getters y setters. Eso puede parecer agradable, pero es una pesadilla de ingeniería inversa.

Digamos que estás mirando a través de cientos de líneas de código y te encuentras con esto:

person.name = "Joe";

Es un código maravillosamente simple hasta que te das cuenta de que es un setter. Ahora, sigue a ese configurador y descubre que también establece person.firstName, person.lastName, person.isHuman, person.hasReallyCommonFirstName y llama a person.update (), que envía una consulta a la base de datos, etc. Oh, eso es donde estaba ocurriendo su pérdida de memoria.

La comprensión de un código local a primera vista es una propiedad importante de buena legibilidad que los captadores y establecedores tienden a romper. Es por eso que trato de evitarlos cuando puedo y minimizar lo que hacen cuando los uso.

Hay muchas razones. Mi favorito es cuando necesitas cambiar el comportamiento o regular lo que puedes establecer en una variable. Por ejemplo, supongamos que tenía un método setSpeed ​​(int speed). Pero desea que solo pueda establecer una velocidad máxima de 100. Haría algo como:

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

Ahora, ¿qué pasa si EN CUALQUIER LUGAR de su código estaba usando el campo público y luego se dio cuenta de que necesita el requisito anterior? Diviértete buscando cada uso del campo público en lugar de solo modificar tu setter.

Mis 2 centavos :)

En un mundo puramente orientado a objetos, los captadores y establecedores son un antipatrón terrible . Lea este artículo: Getters / Setters. Mal. Periodo . En pocas palabras, alientan a los programadores a pensar en los objetos como estructuras de datos, y este tipo de pensamiento es puramente de procedimiento (como en COBOL o C). En un lenguaje orientado a objetos no hay estructuras de datos, sino solo objetos que exponen el comportamiento (¡no atributos / propiedades!)

Puede encontrar más información sobre ellos en la Sección 3.5 de Objetos elegantes (mi libro sobre programación orientada a objetos).

Una ventaja de los accesores y mutadores es que puede realizar la validación.

Por ejemplo, si foofuera público, podría configurarlo fácilmente nully luego alguien más podría intentar llamar a un método en el objeto. ¡Pero ya no está allí! Con un setFoométodo, podría asegurarme de que foonunca se haya configurado null.

Los accesores y los mutadores también permiten la encapsulación: si no se supone que ve el valor una vez que se establece (tal vez se establece en el constructor y luego se usa por métodos, pero nunca se debe cambiar), nadie lo verá nunca. Pero si puede permitir que otras clases lo vean o lo cambien, puede proporcionar el descriptor de acceso y / o mutador adecuado.

Depende de tu idioma. Usted ha etiquetado este "orientado a objetos" en lugar de "Java", por lo que me gustaría señalar que la respuesta de ChssPly76 depende del idioma. En Python, por ejemplo, no hay razón para usar getters y setters. Si necesita cambiar el comportamiento, puede usar una propiedad, que envuelve un captador y definidor alrededor del acceso básico a los atributos. Algo como esto:

class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)

Bueno, solo quiero agregar que incluso si a veces son necesarias para la encapsulación y la seguridad de sus variables / objetos, si queremos codificar un programa orientado a objetos real, entonces debemos DEJAR DE USAR LOS ACCESORIOS , porque a veces dependemos mucho sobre ellos cuando no es realmente necesario y eso hace casi lo mismo que si pusiéramos las variables públicas.

Gracias, eso realmente aclaró mi pensamiento. Ahora aquí hay (casi) 10 (casi) buenas razones para NO usar getters y setters:

1. Cuando se da cuenta de que necesita hacer algo más que establecer y obtener el valor, puede hacer que el campo sea privado, lo que le dirá instantáneamente dónde ha accedido directamente.
   
2. Cualquier validación que realice allí solo puede estar libre de contexto, cuya validación rara vez se practica.
   
3. Puede cambiar el valor que se está configurando; esto es una pesadilla absoluta cuando la persona que llama le pasa un valor que [shock horror] quiere que almacene TAL CUAL.
   
4. Puede ocultar la representación interna: fantástico, por lo que se asegura de que todas estas operaciones sean simétricas, ¿verdad?
   
5. Ha aislado su interfaz pública de los cambios debajo de las hojas: si estaba diseñando una interfaz y no estaba seguro de si el acceso directo a algo estaba bien, entonces debería haber seguido diseñando.
   
6. Algunas bibliotecas esperan esto, pero no muchas: la reflexión, la serialización, los objetos simulados funcionan bien con los campos públicos.
   
7. Al heredar esta clase, puede anular la funcionalidad predeterminada; en otras palabras, puede REALMENTE confundir a las personas que llaman no solo ocultando la implementación sino haciéndola inconsistente.
   

Los tres últimos que acabo de dejar (N / A o D / C) ...

Sé que es un poco tarde, pero creo que hay algunas personas que están interesadas en el rendimiento.

He hecho una pequeña prueba de rendimiento. Escribí una clase "NumberHolder" que, bueno, contiene un número entero. Puede leer ese número entero usando el método getter anInstance.getNumber()o accediendo directamente al número usando anInstance.number. Mi programa lee el número 1,000,000,000 de veces, en ambos sentidos. Ese proceso se repite cinco veces y se imprime el tiempo. Tengo el siguiente resultado:

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

(El tiempo 1 es el camino directo, el tiempo 2 es el captador)

Usted ve, el captador es (casi) siempre un poco más rápido. Luego lo intenté con diferentes números de ciclos. En lugar de 1 millón, utilicé 10 millones y 0.1 millones. Los resultados:

10 millones de ciclos:

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

Con 10 millones de ciclos, los tiempos son casi iguales. Aquí hay 100 mil (0.1 millones) ciclos:

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

También con diferentes cantidades de ciclos, el getter es un poco más rápido que la forma habitual. espero que esto te ayude.

No use getters setters a menos que sea necesario para su entrega actual Es decir, no piense demasiado en lo que sucederá en el futuro, si algo se cambia es una solicitud de cambio en la mayoría de las aplicaciones de producción, sistemas.

Piense simple, fácil, agregue complejidad cuando sea necesario.

No aprovecharía la ignorancia de los dueños de negocios con conocimientos técnicos profundos solo porque creo que es correcto o me gusta el enfoque.

Tengo un sistema masivo escrito sin getters setters solo con modificadores de acceso y algunos métodos para validar y realizar lógica de biz. Si realmente necesitabas el. Usa cualquier cosa.

Utilizamos getters y setters:

• para la reutilización
• para realizar la validación en etapas posteriores de la programación

Los métodos getter y setter son interfaces públicas para acceder a miembros de clases privadas.

Mantra de encapsulación

El mantra de encapsulación es hacer que los campos sean privados y los métodos públicos.

Métodos Getter: podemos obtener acceso a variables privadas.

Métodos de Setter: podemos modificar campos privados.

A pesar de que los métodos getter y setter no agregan nuevas funcionalidades, podemos cambiar de opinión y volver más tarde para hacer ese método

• mejor;
• más seguro y
• Más rápido.

En cualquier lugar donde se pueda usar un valor, se puede agregar un método que devuelva ese valor. En vez de:

int x = 1000 - 500

utilizar

int x = 1000 - class_name.getValue();

En términos simples

Supongamos que necesitamos almacenar los detalles de esto Person. Esto Persontiene los campos name, agey sex. Hacer esto implica la creación de métodos para name, agey sex. Ahora bien, si es necesario crear otra persona, se hace necesaria la creación de los métodos de name, age,sex todo de nuevo.

En lugar de hacer esto, podemos crear un bean class(Person)con métodos getter y setter. Así que mañana podemos crear objetos de este Bean class(Person class)siempre que necesitemos agregar una nueva persona (ver la figura). Por lo tanto, estamos reutilizando los campos y métodos de la clase bean, que es mucho mejor.

Pasé bastante tiempo pensando en esto para el caso de Java, y creo que las razones reales son:

1. Código para la interfaz, no la implementación
2. Las interfaces solo especifican métodos, no campos

En otras palabras, la única forma en que puede especificar un campo en una interfaz es proporcionando un método para escribir un nuevo valor y un método para leer el valor actual.

Esos métodos son el famoso getter y setter ...

Puede ser útil para la carga diferida. Supongamos que el objeto en cuestión está almacenado en una base de datos y no desea obtenerlo a menos que lo necesite. Si un getter recupera el objeto, entonces el objeto interno puede ser nulo hasta que alguien lo solicite, entonces puede obtenerlo en la primera llamada al getter.

Tuve una clase de página base en un proyecto que se me entregó y que estaba cargando algunos datos de un par de llamadas de servicio web diferentes, pero los datos en esas llamadas de servicio web no siempre se usaron en todas las páginas secundarias. Los servicios web, para todos los beneficios, son pioneros en nuevas definiciones de "lento", por lo que no desea realizar una llamada al servicio web si no es necesario.

Me mudé de los campos públicos a los captadores, y ahora los captadores comprueban el caché, y si no está allí, llame al servicio web. Entonces, con un pequeño ajuste, se evitaron muchas llamadas de servicio web.

Entonces el captador me salva de tratar de descubrir, en cada página secundaria, lo que necesitaré. Si lo necesito, llamo al captador, y va a buscarlo si aún no lo tengo.

    protected YourType _yourName = null;
    public YourType YourName{
      get
      {
        if (_yourName == null)
        {
          _yourName = new YourType();
          return _yourName;
        }
      }
    }

Un aspecto que me perdí en las respuestas hasta ahora, la especificación de acceso:

• para los miembros, solo tiene una especificación de acceso para configurar y obtener
• para setters y getters puede ajustarlo y definirlo por separado

EDITAR: Respondí esta pregunta porque hay un montón de personas que aprenden programación preguntando esto, y la mayoría de las respuestas son muy competentes técnicamente, pero no son tan fáciles de entender si eres un novato. Todos éramos novatos, así que pensé en probar una respuesta más amigable para los novatos.

Los dos principales son el polimorfismo y la validación. Incluso si es solo una estúpida estructura de datos.

Digamos que tenemos esta clase simple:

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

Una clase muy simple que contiene la cantidad de líquido que contiene y su capacidad (en mililitros).

¿Qué pasa cuando lo hago?

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

Bueno, no esperarías que eso funcione, ¿verdad? Desea que haya algún tipo de control de cordura. Y peor, ¿qué pasa si nunca especifiqué la capacidad máxima? Oh querido, tenemos un problema.

Pero también hay otro problema. ¿Qué pasaría si las botellas fueran solo un tipo de contenedor? ¿Qué pasaría si tuviéramos varios contenedores, todos con capacidades y cantidades de líquido lleno? Si pudiéramos hacer una interfaz, podríamos dejar que el resto de nuestro programa acepte esa interfaz, y las botellas, bidones y todo tipo de cosas simplemente funcionarían de manera intercambiable. ¿No sería eso mejor? Como las interfaces exigen métodos, esto también es algo bueno.

Terminaríamos con algo como:

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

¡Excelente! Y ahora solo cambiamos Botella a esto:

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

Dejaré la definición de BottleOverflowException como un ejercicio para el lector.

Ahora note cuán más robusto es esto. Podemos lidiar con cualquier tipo de contenedor en nuestro código ahora aceptando LiquidContainer en lugar de Bottle. Y cómo estas botellas manejan este tipo de cosas puede diferir. Puede tener botellas que escriben su estado en el disco cuando cambia, o botellas que guardan en bases de datos SQL o GNU sabe qué más.

Y todo esto puede tener diferentes formas de manejar varios whoopsies. La botella solo comprueba y si se desborda, arroja una RuntimeException. Pero eso podría ser lo incorrecto. (Hay una discusión útil sobre el manejo de errores, pero lo mantengo muy simple a propósito. Las personas en los comentarios probablemente señalarán las fallas de este enfoque simplista.;))

Y sí, parece que pasamos de una idea muy simple a obtener respuestas mucho mejores rápidamente.

Tenga en cuenta también que no puede cambiar la capacidad de una botella. Ahora está en piedra. Podrías hacer esto con un int declarándolo final. Pero si se trata de una lista, puede vaciarla, agregarle cosas nuevas, etc. No puede limitar el acceso a tocar las entrañas.

También está la tercera cosa que no todos han abordado: los captadores y los establecedores usan llamadas a métodos. Eso significa que se ven como métodos normales en cualquier otro lugar. En lugar de tener una sintaxis específica extraña para DTO y otras cosas, tienes lo mismo en todas partes.

En lenguajes que no admiten "propiedades" (C ++, Java) o requieren la recompilación de clientes al cambiar los campos a propiedades (C #), el uso de métodos get / set es más fácil de modificar. Por ejemplo, agregar lógica de validación a un método setFoo no requerirá cambiar la interfaz pública de una clase.

En los lenguajes que admiten propiedades "reales" (Python, Ruby, ¿quizás Smalltalk?) No tiene sentido obtener / establecer métodos.

Uno de los principios básicos del diseño OO: ¡Encapsulación!

Le brinda muchos beneficios, uno de los cuales es que puede cambiar la implementación del getter / setter detrás de escena, pero cualquier consumidor de ese valor continuará trabajando mientras el tipo de datos permanezca igual.

Debes usar getters y setters cuando:

• Estás tratando con algo que es conceptualmente un atributo, pero:
  • Su idioma no tiene propiedades (o algún mecanismo similar, como los rastros variables de Tcl), o
  • El soporte de propiedad de su idioma no es suficiente para este caso de uso, o
  • Las convenciones idiomáticas de su idioma (o, a veces, su marco) alientan a los captadores o establecedores para este caso de uso.

Por lo tanto, rara vez es una pregunta general de OO; es una pregunta específica del idioma, con diferentes respuestas para diferentes idiomas (y diferentes casos de uso).

Desde el punto de vista de la teoría OO, los captadores y los establecedores son inútiles. La interfaz de su clase es lo que hace, no cuál es su estado. (Si no, ha escrito la clase incorrecta.) En casos muy simples, donde lo que hace una clase es, por ejemplo, representar un punto en coordenadas rectangulares, * los atributos son parte de la interfaz; getters y setters solo nublan eso. Pero en todo menos en casos muy simples, ni los atributos ni los captadores y definidores son parte de la interfaz.

Dicho de otra manera: si crees que los consumidores de tu clase ni siquiera deberían saber que tienes un spamatributo, y mucho menos ser capaz de cambiarlo de manera involuntaria, entonces darles un set_spammétodo es lo último que quieres hacer.

_{* Incluso para esa clase simple, es posible que no desee permitir establecer los valores xy y. Si esto es realmente una clase, que no debería tener métodos como translate, rotate, etc.? Si es solo una clase porque su lenguaje no tiene registros / estructuras / tuplas con nombre, entonces esto no es realmente una cuestión de OO ...}

Pero nadie está haciendo un diseño general de OO. Están haciendo diseño e implementación en un lenguaje específico. Y en algunos idiomas, getters y setters están lejos de ser inútiles.

Si su lenguaje no tiene propiedades, entonces la única forma de representar algo que es conceptualmente un atributo, pero que en realidad se calcula, o se valida, etc., es a través de getters y setters.

Incluso si su idioma tiene propiedades, puede haber casos en los que sean insuficientes o inapropiados. Por ejemplo, si desea permitir que las subclases controlen la semántica de un atributo, en idiomas sin acceso dinámico, una subclase no puede sustituir una propiedad calculada por un atributo.

En cuanto a "¿y si quiero cambiar mi implementación más tarde?" pregunta (que se repite varias veces en diferentes palabras tanto en la pregunta del OP como en la respuesta aceptada): si realmente es un cambio de implementación puro, y usted comenzó con un atributo, puede cambiarlo a una propiedad sin afectar la interfaz. A menos que, por supuesto, su idioma no lo admita. Así que este es realmente el mismo caso nuevamente.

Además, es importante seguir los modismos del lenguaje (o marco) que está utilizando. Si escribe un hermoso código de estilo Ruby en C #, cualquier desarrollador experimentado de C # que no sea usted tendrá problemas para leerlo, y eso es malo. Algunos lenguajes tienen culturas más fuertes en torno a sus convenciones que otros. Y puede que no sea una coincidencia que Java y Python, que se encuentran en extremos opuestos del espectro por lo idiomáticos que son los captadores, tengan dos de las culturas más fuertes.

Más allá de los lectores humanos, habrá bibliotecas y herramientas que esperan que sigas las convenciones y te hagan la vida más difícil si no lo haces. Conectar widgets de Interface Builder a cualquier cosa que no sean las propiedades de ObjC, o usar ciertas bibliotecas de burla de Java sin getters, simplemente te está haciendo la vida más difícil. Si las herramientas son importantes para ti, no luches contra ellas.

Desde el punto de vista del diseño de orientación a objetos, ambas alternativas pueden ser perjudiciales para el mantenimiento del código al debilitar la encapsulación de las clases. Para una discusión, puede consultar este excelente artículo: http://typicalprogrammer.com/?p=23

Los métodos getter y setter son métodos de acceso, lo que significa que generalmente son una interfaz pública para cambiar los miembros de la clase privada. Utiliza métodos getter y setter para definir una propiedad. Accede a los métodos getter y setter como propiedades fuera de la clase, aunque los defina dentro de la clase como métodos. Esas propiedades fuera de la clase pueden tener un nombre diferente del nombre de la propiedad en la clase.

El uso de métodos getter y setter tiene algunas ventajas, como la capacidad de permitirle crear miembros con funcionalidades sofisticadas a las que puede acceder como propiedades similares. También le permiten crear propiedades de solo lectura y de solo escritura.

Aunque los métodos getter y setter son útiles, debe tener cuidado de no usarlos en exceso porque, entre otros problemas, pueden dificultar el mantenimiento del código en ciertas situaciones. Además, proporcionan acceso a la implementación de su clase, como los miembros públicos. La práctica de OOP desalienta el acceso directo a las propiedades dentro de una clase.

Cuando escribe clases, siempre se le recomienda que haga privadas la mayor cantidad posible de sus variables de instancia y que agregue métodos getter y setter en consecuencia. Esto se debe a que hay varias ocasiones en las que es posible que no desee que los usuarios cambien ciertas variables dentro de sus clases. Por ejemplo, si tiene un método estático privado que rastrea el número de instancias creadas para una clase específica, no desea que un usuario modifique ese contador utilizando el código. Solo la declaración del constructor debe incrementar esa variable siempre que se llame. En esta situación, puede crear una variable de instancia privada y permitir un método getter solo para la variable counter, lo que significa que los usuarios pueden recuperar el valor actual solo mediante el método getter, y no podrán establecer nuevos valores utilizando el método setter.

El código evoluciona . privatees ideal para cuando necesita protección de miembros de datos . Eventualmente, todas las clases deberían ser una especie de "miniprogramas" que tienen una interfaz bien definida que no se puede simplemente atornillar con lo interno .

Dicho esto, el desarrollo de software no se trata de establecer esa versión final de la clase como si estuvieras presionando alguna estatua de hierro fundido en el primer intento. Mientras trabajas con él, el código es más como arcilla. Evoluciona a medida que lo desarrollas y aprendes más sobre el dominio del problema que estás resolviendo. Durante el desarrollo, las clases pueden interactuar entre sí de lo que deberían (dependencia que planea descontar), fusionarse o separarse. Así que creo que el debate se reduce a personas que no quieren escribir religiosamente

int getVar() const { return var ; }

Así que tienes:

doSomething( obj->getVar() ) ;

En vez de

doSomething( obj->var ) ;

No solo es getVar()visualmente ruidoso, sino que da la ilusión de que de gettingVar()alguna manera es un proceso más complejo de lo que realmente es. La forma en que usted (como escritor de la clase) considera que la santidad vares particularmente confusa para un usuario de su clase si tiene un setter passthru, entonces parece que está poniendo estas puertas para "proteger" algo que insiste es valioso, (la santidad de var), pero aun así usted reconoce que varla protección no vale mucho por la capacidad de cualquiera de entrar yset var al valor que quiera, sin siquiera mirar lo que están haciendo.

Así que programo de la siguiente manera (suponiendo un enfoque de tipo "ágil", es decir, cuando escribo código sin saber exactamente lo que hará / no tengo tiempo o experiencia para planificar un elaborado conjunto de interfaces de estilo cascada):

1) Comience con todos los miembros públicos para objetos básicos con datos y comportamiento. Es por eso que en todo mi código de "ejemplo" de C ++ me notarás usando en structlugar de en classtodas partes.

2) Cuando el comportamiento interno de un objeto para un miembro de datos se vuelve lo suficientemente complejo (por ejemplo, le gusta mantener un interno std::listen algún tipo de orden), se escriben las funciones de tipo de acceso. Debido a que estoy programando solo, no siempre establezco el miembro de privateinmediato, pero en algún momento de la evolución de la clase, el miembro será "promovido" a uno protectedu otro private.

3) Las clases que están completamente desarrolladas y tienen reglas estrictas sobre sus componentes internos (es decir , saben exactamente lo que están haciendo, y no debe "joder" (término técnico) con sus classcomponentes internos) reciben la designación, miembros privados predeterminados, y solo unos pocos miembros selectos pueden ser public.

Creo que este enfoque me permite evitar sentarme allí y escribir religiosamente getter / setters cuando muchos miembros de datos se migran, cambian de lugar, etc. durante las primeras etapas de la evolución de una clase.

Hay una buena razón para considerar el uso de accesores si no hay herencia de propiedad. Ver siguiente ejemplo:

public class TestPropertyOverride {
    public static class A {
        public int i = 0;

        public void add() {
            i++;
        }

        public int getI() {
            return i;
        }
    }

    public static class B extends A {
        public int i = 2;

        @Override
        public void add() {
            i = i + 2;
        }

        @Override
        public int getI() {
            return i;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.i);
        a.add();
        System.out.println(a.i);
        System.out.println(a.getI());
    }
}

Salida:

0
0
4

Getters y setters se utilizan para implementar dos de los aspectos fundamentales de la Programación Orientada a Objetos que son:

1. Abstracción
2. Encapsulamiento

Supongamos que tenemos una clase de empleado:

package com.highmark.productConfig.types;

public class Employee {

    private String firstName;
    private String middleName;
    private String lastName;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
       this.firstName = firstName;
    }
    public String getMiddleName() {
        return middleName;
    }
    public void setMiddleName(String middleName) {
         this.middleName = middleName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getFullName(){
        return this.getFirstName() + this.getMiddleName() +  this.getLastName();
    }
 }

Aquí los detalles de implementación del Nombre completo están ocultos para el usuario y no son accesibles directamente para el usuario, a diferencia de un atributo público.

Otro uso (en lenguajes que admiten propiedades) es que los establecedores y captadores pueden implicar que una operación no es trivial. Por lo general, desea evitar hacer algo que sea computacionalmente costoso en una propiedad.

Una ventaja relativamente moderna de los captadores / establecedores es que facilita la exploración del código en editores de código etiquetados (indexados). Por ejemplo, si desea ver quién establece un miembro, puede abrir la jerarquía de llamadas del establecedor.

Por otro lado, si el miembro es público, las herramientas no permiten filtrar el acceso de lectura / escritura al miembro. Por lo tanto, debe caminar a través de todos los usos del miembro.

En un lenguaje orientado a objetos, los métodos y sus modificadores de acceso declaran la interfaz para ese objeto. Entre el constructor y los métodos de acceso y mutación, es posible que el desarrollador controle el acceso al estado interno de un objeto. Si las variables simplemente se declaran públicas, entonces no hay forma de regular ese acceso. Y cuando usamos setters podemos restringir al usuario para la entrada que necesitamos. Significa que el feed para esa variable muy vendrá a través de un canal apropiado y el canal está predefinido por nosotros. Por lo tanto, es más seguro usar setters.

Además, esto es para "preparar el futuro" de su clase. En particular, cambiar de un campo a una propiedad es una ruptura de ABI, por lo que si luego decide que necesita más lógica que simplemente "establecer / obtener el campo", entonces necesita romper ABI, lo que por supuesto crea problemas para cualquier cosa más ya compilado contra su clase.

Solo me gustaría lanzar la idea de la anotación: @getter y @setter. Con @getter, debería poder obj = class.field pero no class.field = obj. Con @setter, viceversa. Con @getter y @setter deberías poder hacer ambas cosas. Esto preservaría la encapsulación y reduciría el tiempo al no llamar a métodos triviales en tiempo de ejecución.