Bueno, aunque estoy de acuerdo al 90% con Sixto, creo que es necesario
ver la cara B de todo esto. A m� personalmente "las normas" me la traen
al fresco --y seguro que a muchos de vosotros tambi�n-- cuando se trata
de un grupo muy cerrado de coders, sobre todo si el que tiene que hacer
las cosas soy yo s�lo.
L�gicamente si existe una "norma" o "best practice" para esto es porque
es la forma �ptima de hacerlo. No obstante, seguir todas las normas no
siempre es posible en el mundo real de stress y deadlines tan
jodidamente cerrados; siempre se acaba por utilizar m�todos caseros y,
sobre todo en el caso de flash que es muy tricky, la mayor�a de los
casos se acaba por tirar por borda parte de la metodolog�a OOP --qui�n
no haya hecho nunca una megaclase con millones de m�todos que tire la
primera piedra--.
Pero esto es algo m�s que una norma. No es �nicamente una norma de
dise�o ni del proceso unificado (UP) de desarrollo de software. Si bien
con accesors ganamos en bajo acoplamiento (low coupling) no es el �nico
beneficio que nos reporta. Algui�n podr�a pensar: "total, mi megaclase
tiene un coupling de la ostia" y dejar de lado los beneficios de los
accesors y creo que es lo que debe evitarse.
Los accesors simples del tipo:
Get() {
return miembro;
}
Set(valor) {
miembro = valor;
}
s�lo ayudan, aparentemente, a ocultar la informaci�n (principio *b�sico*
de oop, junto con el low coupling, la cohesi�n y el dise�o estructurado)
pero no parecen aportar nada m�s a nuestro c�digo.
Pues bien, aportan bastante m�s que ocultar informaci�n y minimizar
acoplamiento, sobre todo en la extensibilidad de la clase. En un nivel
inicial de get/set b�sico, como el anterior, lo �nico que hacemos es
acceder a un miembro de la clase y devolver su valor pero haciendo uso
de get/set ayudamos a la extensibilidad del c�digo: podemos dejar
abierto el get/set para luego refactorizarlo si fuese necesario (que el
get dependiese del handshaking de otra clase, por ejemplo) y, de esta
forma, no tendr�amos que cambiar todo el c�digo:
Get() {
otroValor = otraClase.Get()
if (valor > otroValor) {
return miembro;
}else{
return otroValor;
}
}
Set(valor) {
miembro = valor;
otraClase.Set(valor)
}
Un saludo,
M.
-----Mensaje original-----
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
En nombre de [EMAIL PROTECTED]
Enviado el: mi�rcoles, 05 de noviembre de 2003 11:21
Para: [EMAIL PROTECTED]
Asunto: Re: [ASNativos] Accesors
Hola a todos:
El motivo de usar getter y setters para acceder a variables internas de
una
clase, no es mas que cumplir con las bases de la encapsulaci�n.
Una norma dentro de la encapsulaci�n es que todo clase que acceda a
otra, no
debe saber mas que una interfaz de uso b�sica, obligando a desconocer el
contenido interno de la clase o su funcionamiento.
Esto garantiza el bajo acoplamiento entre clases, una explicaci�n sobre
el
concepto de acoplamiento est� en el post de www.code4net.com
llamado "Patrones?"...
<!-------------------------------
Lista ASNativos:
subscripciones/desubscripciones
http://www.sidedev.net/asnativos
-------------------------------->
