2008/4/24 Abel Fillol <[EMAIL PROTECTED]>:
> Sencillamente no tienen idea de lo que están hablando...
>
> Los getters y setters son sumamente útiles por muchos motivos, los mas
> básicos son que AYUDAN a la legibilidad, ya que si yo pongo
Primero que nada, ayudaran solo en Java por ser
minimalista/restrictivo/paratenerprogramadoresbaratosyquenohagancagadas,
Si analizamos mas alla de Java, no tienen sentido (que fue lo que Luca
quizo exponer)
> this.getAlgo().toString, claramente estoy haciendo referencia al atributo
> "algo" de mi objeto, en cambio si pongo algo.toString, uno a simple vista no
> sabe si ese "algo" es un atributo de la clase, es una variable local, me lo
> pasaron por parámetro es un método que devuelve _algo_ , etc.
Es que justamente no te importa si es un metodo que retorna un String,
si es un String, o si es un wrapper que retorna un String debido a que
tiene aplicado un decorator.
Ruby por ejemplo dio un pasito mas (seguro se lo robo a alguien, no se
a quien :P) : Los () son opcionales!, es decir, si yo te digo :
if params[:pepe] == 'popo'
Vos no me vas a poder decir si params es una variable local, un metodo
o que, pero la legibilidad no se afecta (de hecho mejora). Por que?
Porque no te deberia importar. Vos sabes que tenes un hash, es todo lo
que necesitas saber, no importa de que manera te llega.
if params()[:pepe] es muhcho menos legible, y if
controller.params()[:pepe] mucho menos aun.
> Por otro lado, si hubieran trabajado en alguna aplicación medianamente
> grande, sabrían que muchas veces los atributos de clases pueden necesitar
> ser auditados, sincronizados, o disparar cualquier tipo de acción cada vez
> que se los utilice o cada vez que se cambie el valor. Si se respetara el uso
> de getters y setters, solo tengo que agregarle algún aspecto a la clase que
> reaccione ante la llamada del getter o setter y haga su magia.
En este caso el util. De todo modos, tener properties en el lenguaje
hace que siga siendo mas bonita la notacion, pero sin perder esta
opcion.
Ejemplo C#.NET :
class A {
private int i;
public int I { get { return i; } set { i =value } }
}
A a = new A();
a.i = 2
es mucho mas lindo que leer : a.setI(2)
> En otro ejemplo, supongamos una clase A que contiene un atributo b que es
> una instancia de una clase B que a su vez tiene una colección de C. Es
> importante saber que algunos frameworks, al levantar una instancia de A no
> hidratan todos sus atributos (para no ocupar memoria ni tiempo buscando en
> la base cosas, que quizás nunca uses), y si no accedemos a estos por los
> getters, el framerowk no se entera que lo accedimos, nunca lo hidrata y nos
> va a decir que tenemos un null si hacemos a.b cuando en la base de datos si
> teníamos bs que tenían cs. Una vez mas, magia de aspectos.
Eso se arregla facil con un framework que sepa hacer cosas lazy,
claro, java no tiene nada lazy :P, las properties de nuevo al rescate.
> por último, lo que hoy es un atributo de la clase mañana puede llegar a ser
> un cálculo o por alguna razón habría que evitar un null por salida, en ese
> caso, solo se toca el getter sin necesidad de nada mas.
Llegado al caso, si tenias un atributo public, es facil refactorizar.
Lo haces privado con otro nombre, agregas un publico con el mismo
nombre que lo tenias antes y armas setters y getters.
> Creo que muchas personas podrían llegar a agregar mucho a esta lista que
> acabo de escribir, pero la verdad es que el nivel de soberbia, agresividad e
> ignorancia que se vió en este hilo hace que los que tienen cosas
> interesantes que decir se abstengan de tirarle perlas a los chanchos.
La verdad que no hay excusa para set un abusivo de get/set, es una
vicio de Java y de los que enseñan a desarrollar. Si no hay motivo
aparente, tener todo publico NO es un problema. Si necesitas ocultar
algo por alguna razon, tener properties es preferible a getter/setters
explicitos, ya que mejoran la lectura.
> Quizás sea bueno aclarar que no leí el hilo anterior, pero me interesó el
> tema de getters y setters porque es algo que el 99% de los juniors que vi
> pasar a mi lado (incluyéndome hace años atrás) tenían el mismo concepto
> erróneo.
No es erroneo, es diferente.
> PD: también usen this. cada vez que puedan. :D
Tenes que acostumbrarte a pensar "beyond Java" .... hay un mundo
muuuuuuuuucho mas grande :)
_______________________________________________
Lista de correo Programacion.
[email protected]
http://listas.fi.uba.ar/mailman/listinfo/programacion
