Fijense que el deseo de que un objeto sea inmutable o no depende de lo que uno quiera hacer con el...
2009/6/4 Nahuel Silva <[email protected]>: > 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 -~----------~----~----~----~------~----~------~--~---
