#1105 enumero:
- Acceder directamente a un campo puede provocar errores de asignacion indeseada. No es la primera vez que alguien ha puesto un
if (position.x = 0.0f)por error provocando bugs bastante chungos de encontrar, o que incluso pasan desapercibidos. Si tienes la costumbre de comparar la constante con la variable no ocurre, pero no todo el mundo lo hace asi.
No hacerlo provoca el antipattern Object Orgy: https://en.wikipedia.org/wiki/Object_orgy
Quieres restringir el rango de valores de determinado campo (ej. un poligono tiene que tener tres o mas lados).
Todos los objetos que se crean deberian ser inmutables (los lenguajes funcionales suelen hacerlo). Si expones los campos y los haces modificables violan este principio.
Tienes funciones con mucho coste computacional, y necesitas cachear el resultado para que solo se ejecutan la primera vez. Si dejas el campo que se usa para cachear a la vista, se podra acceder a el accidentalmente cuando aun no esta inicializado. Con un getter podrias usar lazy loading para inicializar los valores necesarios la primera vez que se accede.
Los campos no pueden definirse en interfaces, por lo que no podrias implementar dependency injection, violando los principios ISP y DIP de SOLID.
Y ya paro que no quiero pensar mas.
#1111 Puedes extender la inmutabilidad de los objetos?
Para mi no siempre es worth tener todo inmutable.
#1110 Esa optimizacion no vale la pena ni mucho menos para los problemas que acarrea. En el getter que vas a hacer? Comprobar si es nulo para crear otro? Codigo sucio.
Unas coordenadas no es un gasto en memoria que deba preocuparte. Si vas a tener muchos miembros sin utilizar segun la instancia que lo utilice, preguntate si esta bien definida la clase o si necesitas herencias.
Yo una vez dije que el uso de getter setters rompe la encapsulación de objetos y significa una clase mal implementada y me pusieron de hijo de la gran puta para arriba, avisados quedáis XD .
Que harían algunos en el mundo Java sin la posibilidad de "testear" los métodos get/set de para subir % de cobertura de test en Sonar...
De stackoverflow:
There are actually many good reasons to consider using accessors rather than directly exposing fields of a class - beyond just the argument of encapsulation and making future changes easier.
Here are the some of the reasons I am aware of:
-Encapsulation of behavior associated with getting or setting the property - this allows additional functionality (like validation) to be added more easily later.
-Hiding the internal representation of the property while exposing a property using an alternative representation.
-Insulating your public interface from change - allowing the public interface to remain constant while the implementation changes without affecting existing consumers.
-Controlling the lifetime and memory management (disposal) semantics of the property - particularly important in non-managed memory environments (like C++ or Objective-C).
-Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
-Improved interoperability with libraries that are designed to operate against property getter/setters - Mocking, Serialization, and WPF come to mind.
-Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
-Allowing the getter/setter to be passed around as lambda expressions rather than values.
-Getters and setters can allow different access levels - for example the get may be public, but the set could be protected.
Y el más mejor:
Because 2 weeks (months, years) from now when you realize that your setter needs to do more than just set the value, you'll also realize that the property has been used directly in 238 other classes :-)
Sólo en casos muy excepcionales no usaría getters y setters por defecto. ¿Te preocupa muchísimo el rendimiento? vale, tira con tus campos públicos, pero aparte de eso no veo ningún otro motivo para no usarlas siempre.
#1122 Ese comentario parte de la base que no usar getters/setters significa poner las variables miembro como públicas y no es de lo que se trata. Quien critica los getter/setters y usa variables miembro públicas tiene el mismo problema de base.
Ah se me olvidaba la imagen graciosa:
#1124 El debate no es usar getter/setters o miembros públicos sino implementar correctamente la clase, ponerlas las variables públicas a saco es un incluso peor. Evidentemente si me dan a elegir entre usar un getter/setter o poner la variable pública me decanto por la primera opción si no me queda otros cojones ( código ya usando getter/setter, uso de librerías que te obligan a ello, etc) pero la solución al problema no pasa por esas dos opciones. Es un tema complejo porque cada uno interpreta este área de una forma diferente pero si hablamos estrictamente está en contra de la encapsulación en POO.
#1125 a mí es lo que me han enseñado, que no puedo romper la encapsulación. Si la rompía me cascaban un 0 X)
#1125 ¿Cómo pueden ir en contra de la encapsulación los getters y setters? precisamente son esos métodos los que permiten, por ejemplo, hacer un campo de lectura pero no de escritura o viceversa, cosa que no se puede hacer con "public", "private", etc.
Por supuesto que una clase no está bien implementada si el acceso a sus miembros es un sinsentido, pero de ahí a decir que los getters y setters van en contra de la encapsulación hay un trecho xD
#1127 Para empezar usándolos estás dando información de como está estructurada la clase, puedes manipular esos datos implementando la clase de mil formas sin tener que exponer la estructura de tu clase. Pongo un ejemplo para que veas lo que quiero decir:
MAL
clase Pelota{
variable posX privada
método público getX()
método público setX(pos)
}
BIEN
clase Pelota{
variable posX privada
método público obtenerPosicion()
método público mover(pos)
}
Y dirás, "coño pero si es lo mismo", pues no porque en el segundo ejemplo no expones la estructura y está definida la clase pensando en ella como un objeto no un simple almacén de datos.
EDIT: actualizado para que se vea más claro lo que quiero decir.
Es lo mismo, ni filosofía ni leches, le cambias el nombre a un metodo "set" para que no se llame "set" xD
#1130 Realmente creo que el monete tiene razón, ¿cuál es si no la diferencia entre una clase y un struct?
gente.
algun libro para empezar con programacion? pseudocodigo, paradigmas... para aprender conceptos antes de ponerme con un lenguaje especifico. he visto varios libros, pero no se por cual empezar, veo uno y es en plan, meh, seguro que hay otro mejor xD
lo que si, son la mayoria en ingles, y no estaria mal verlos en español, que mi ingles es de paletos jaja
gracias.
#1134 te puedo dejar uno MUY BUENO con el que yo aprendí a programar (es el que me dieron en la uni). Está en PASCAL, pero para aprender a programar de 0 es lo mejor, está muy bien explicado. Está en español.
Si te interesa mandame un mp y lo busco entre mis apuntes xD
#1134 Yo empecé con C , parece un poco absurdo al principio pero una vez lo aprendes el resto de lenguajes son similares
Decid lo que queráis pero las variables públicas son una mierda. Y si en vez de ver o ser queréis usar por ejemplo mover es otra mierda porque te acabará confundiendo al programador y tendrá que estar buscando continuamente que nombres le puso al método con anterioridad. Puede que en un proyecto pequeño sirva pero en uno grande se hace pesado.
#1136 pero me gustaria aprender mas conceptos que un lenguaje en concreto.
no se si me explico xD
¿cuál es si no la diferencia entre una clase y un struct?
Fyn4r: ninguna xD
Es lo mismo, ni filosofía ni leches, le cambias el nombre a un metodo "set" para que no se llame "set" xD
No pongo imagen graciosa porque con las citas ya os deberíais estar partiendo la caja. Si veis una clase como un simple almacén de datos nunca entenderéis el concepto de programación orientada a objetos.
#1139 lo que tu digas bro, pero espero que no me estés diciendo en serio que llamar a un método "mover" en vez de "set" va a exponer menos la estructura de tu clase.
