Setters y getters

> de: Andres Valloud
>  
>
> El problema, basicamente, es que no hay un solo punto de vista con
> respecto a los accessors cuando se considera la encapsulacion.  Lo que
> entendemos por encapsulacion cambia segun nuestras intenciones, porque
> lo que queremos es lo que dibuja los bordes que despues nos permiten
> decir que algo esta encapsulado.
>
> Estan aquellos que dicen "las variables x, y, z son detalles internos
> de implementacion de TalClase, y por lo tanto no tiene que haber
> accessors [getters/setters] porque si no otros objetos podran
> manipular detalles internos, violando la encapsulacion".
>
> Desde el punto de vista del proposito de los objetos considerados
> individualmente, quiza haya algo de sentido en ese argumento.  Pero
> los que lidiamos con las consecuencias somos nosotros, y ademas
> nosotros tenemos un punto de vista mas abarcador.  Tambien usamos
> puntos de vista meta, que estan mas alla del proposito individual de
> cada objeto.  Hay propositos perfectamente validos, como por ejemplo
> encontrar todas las instancias de TalClase tales que sus variables de
> instancia estan rotas.  Tipica expresion de debugger:
>
> TalClase allInstances select: [:any | any z esCualquiera]
>
> Sin accessors, esto es imposible.  Las alternativas son por demas
> molestas... seguro, siempre es posible usar instVarAt:, pero por que
> la necesidad de ser tan bruto (en el sentido de la fuerza bruta)?  Y
> si instVarAt: existe, porque preocuparse de los accessors y la
> encapsulacion?  Hay que redefinir instVarAt: como shouldNotImplement,
> acaso?  Entonces, desde nuestro punto de vista, la encapsulacion no
> existe necesariamente siempre en el mismo lugar, porque en presencia
> de instVarAt: e instVarAt:put: vale cualquier cosa.  Lo que si es
> interesante es que nosotros decimos eso porque sabemos como esta
> implementado instVarAt:.  Los objetos no saben, necesariamente.  Creo
> que aca es donde se arma la galleta: la confusion entre nuestro punto
> de vista, y el punto de vista mas estrecho de cada objeto.
>
> A mi gusto, los que programamos somos nosotros.  Entonces, por nuestro
> propio beneficio, tiene que haber accessors para todas las variables
> de instancia.  Esto hace mas facil debuggear objetos rotos.  Ademas,
> facilita browsear codigo porque las referencias a las variables de
> instancia no pasan de 2 metodos (en algunos casos de lazy
> initialization se puede hacer "bien" con un metodo, pero entonces no
> hay setters y a veces molesta porque no hay z: para arreglar las
> instancias de TalClase donde z esCualquiera).  Incluso facilita
> encontrar errores porque si interesa enterarse de cuando una variable
> de instancia cambia a un valor critico, la presencia del setter hace
> que solo haya que poner UN breakpoint.  Cambiar la estructura interna
> de los objetos con accessors es trivial, ya que desde el punto de
> vista de los objetos la implementacion de los mensajes SI esta
> encapsulada.
>
> Pero que hacer con los objetos que mandan setters que no deberian
> mandar, no?  Para esto, lo que me parece mejor es poner los setters
> que son privados en un protocolo llamado "private - accessing" o algo
> parecido, y no usarlos donde no corresponde.  Una buena revision de
> codigo siempre elimina cualquier caso en el que se te escape un
> mensaje inapropiado.
>
> Cada tanto escucho excusas del estilo "ahh, pero como te aseguras
> nadie va a mandarse una guarangada?".  A mi gusto, la mejor solucion
> es que aquellos que sientan que saben algo valioso lo compartan y lo
> enseñen.  O sea, en vez de prohibir accessors y privarnos de sus
> beneficios, programemos mejor.  Ademas, nada impide escribir un test
> que verifique que aquellos mensajes en protocols llamados 'private*'
> no se mandan desde cualquier lugar.
>
> Para sintetizar entonces... accessors para todas las variables de
> instancia porque hacen mas facil programar, browsear, debuggear, y
> cambiar la estructura de los objetos minimizando los cambios
> secundarios indeseados.  Los que sean privados, favor de ponerlos en
> un protocolo que se llame 'private*', y no mandarlos de maneras
> irresponsables desde un punto de vista concreto como el que tienen los
> objetos individuales.
>
> Andres.
>
> Me encantaría escuchar opiniones al respecto.
>
> Edgar
>