Que interesante lo que decís Juan....lo de la inmutabilidad, me suena conocido no se por qué... :-p.
Respecto a la inmutabilidad de Point, no se si estoy tan de acuerdo; o sea suena lógico que un punto sea único e inmutable; pero no es lo mismo tener un punto que se mueve por toda la pantalla (aPointA x: algunXDePantalla y: algunYDePantalla, que tener, n*(xPantalla*yPantalla) posibles instancias de puntos a representar en pantalla, -que supondrían ser el inicial, dandose por muertas cada vez que un nuevo punto aparece-, sin embargo pese a darse por muerta cada instancia anterior, sería ridículo estar creando puntos a lo loco no ?. P.D.: Puntero (sust. masculino):También utilizado para golpear niños rebeldes Abrazo 2009/6/3 Juan Buligovich <[email protected]> > > Aclaro algo para que no se entienda mal la palabra puntero que utilicé en > el > mail anterior. > Puntero = Esa varilla con que los profesores de la antigüedad utilizaban > para señalar en el pizarrón. O sea: un dispositivo que sirve para señalar > puntos de una superficie, uno por vez. > > ----- Original Message ----- > From: "Juan Buligovich" <[email protected]> > To: <[email protected]> > Sent: Wednesday, June 03, 2009 11:13 PM > Subject: Re: [clubSmalltalk] Re: setters y getters > > > > Hola > > > > Leyendo el mail inicial de Nahuel veo que hace referencia a un concepto, > > que sería el motivo que lo llevó al otro a prescindir de los setters: el > > concepto de inmutabilidad. > > > > A mí me parece que si uno está definiendo el protocolo de un objeto > > inmutable ¿para qué ponerle setters? ¿para qué ofrecer un servicio que no > > se va a utilizar? ¿o mejor dicho, que se utiliza solamente en el momento > > de la creación del objeto, y que puede ser expresado mejor como > > inicialización de las variables de instancia que como el seteo individual > > de cada una de ella? > > > > Supongamos que el Point de Smalltalk fuera tal objeto inmutable, y se > > hubiera definido así en Smalltalk, en ese caso bastaría con el protocolo > > #x:y: en Point class, y un método de inicialización como parte del > > protocolo privado de la instancia > > > > Point class>>x: xCoord y: yCoord > > ^self basicNew initializeWithX: xCoord y: yCoord > > > > Point>>initializeWithX: xCoord y: yCoord > > x := xCoord. > > y := yCoord > > > > Point>>x > > ^x > > > > Point>>y > > ^y > > > > etc. > > > > ¿Y porqué meterse con conceptos como el de inmutabilidad? > > Porque fundamentalmente un objeto inmutable tiene una existencia más > > simple, y no está expuesto al problema de la identidad. > > > > El tema de la identidad y de la inmutabilidad creo que es un temón, muy > > intereseante, pero que excede al de la temática de los setters. Tuve la > > oportunidad de asistir a una clase magistral que dio Dan Rozenfarb en la > > materia de Diseño Avanzado con Objetos, y luego a otra que dio Hernán > > Wilkinson sobre la misma temática. Y una de las conclusiones fue que los > > objetos inmutables son objetos mucho más simples de utilizar, por lo > tanto > > si queremos representar algo que es visto como inmutable, no perdamos la > > oportunidad de construirlo como inmutable en nuestro modelo. > > > > Ejemplos típicos de objetos inmutables de en la "realidad" serían los > > objetos matemáticos, como es el caso de los números. Y como es el los > > pares ordenados que representan puntos en el espacio bidimensional. De > ahí > > que cuando pregunté si no hubiera sido mejor que el Point de Smalltalk > > fuera inmutable, Hernán respondió que sí, que no hay ningún motivo para > > que Point sea mutable , y que hubiera sido un mejor diseño en Smalltalk > un > > Point inmutable. > > > > Un punto representa un punto en el espacio. Y si queremos tener otro > punto > > en el espacio podemos construir otro punto, y punto. A mi entender el > > Point de Smalltalk más que punto es un puntero. Uno puede utilizarlo como > > punto mediante la disciplina de no enviar los mensajes de setting, pero > > ¿para qué cargarse con reglas disciplinarias cuando en Smalltalk es tan > > fácil construir la representación del concepto deseado y luego utilizar > > los objetos que lo instancian con toda libertad, como al boleo? > > > > Saludos > > Juan > > > > ----- Original Message ----- > > From: "Andres Valloud" <[email protected]> > > To: <[email protected]> > > Sent: Tuesday, June 02, 2009 6:17 PM > > Subject: [clubSmalltalk] Re: setters y getters > > > > > > > > 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. > > > > > > 2009/6/2 Nahuel Silva <[email protected]>: > >> Hola gente. > >> > >> Les cuento, en el trabajo discutiendo con mi compañero sobre accesors no > >> logramos llegar a un acuerto. > >> Mis críticas son que en la mitad de sus clases no estan definidos los > >> accesors (tanto setters como gettters) y me resulta no solo bastante > >> engorroso debugguear el código, ya que de repente aparece una variable, > >> variableA y no sabés de donde carajo sale, sino que yo entiendo que > >> programar en smalltalk sin accesors (setters) está mal y el considera > que > >> no, argumentando historietas sobre objetos inmutables y otras yerbas, > que > >> no > >> quita que sa ea correcto. > >> > >> Que me pueden decir ustedes, que consideraciones puedo tener a la hora > de > >> determinar cuando usar accesors, cuándo definirlos, que criterio tengo > en > >> cuenta ?. Ésto es una pavada (tal vez), pero quiero más opiniones. > >> > >> Abrazo > >> > >> Nahuel > >> > >> > > >> > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
