Diego, Acerca de subclassResponsibility y shouldNotImplement... > > Y eso es porque en un proyecto terminado no deberían existir ni esos > > senders ni la implementación de los mismos. > >
Y no... por lo menos en cuanto a la conducta del programa, no. A mi gusto son doesNotUnderstand: comentados, basicamente, que sirven para no caer en la tentacion de hacer cosas simples que despues cuestan mucho a largo plazo. En ese sentido, aun sin tener senders no me parece una buena idea borrarlos necesariamente. > > Dicho esto y volviendo a los accessors creo que la cuestión no pasa > > por saber si ponerlos o no, sino en qué momento del desarrollo hay que > > implementarlos. El desarrollo en si no termina nunca, salvo que el proyecto se cancele en cuyo caso la presencia de los accessors mucho no importa. En terminos de desarrollo, como decis... > > Y esto vale para cualquier método. En la mayoría de > > las comunicaciones, el responsable del mensaje es el emisor y en los > > objetos esto creo que se aplica. Son los emisores de mensajes quienes > > definen las interfaces y no el buen diseño que supuestamente se pensó > > de antemano. > > ... a mi gusto el tema es que por un lado uno dice "ah no, los objetos tales y cuales no deberian mandar estos y aquellos mensajes". Por otro lado, a mi los accessors me sirven cuando pienso en un nivel meta mas elevado que el de la aplicacion en si. Ejemplos tipicos... encontrar objetos rotos con allInstances select: [:x | x talVariable talCosa]. Sin accessors, imposible. O si no, cambiar la estructura interna de un objeto sin tener que cambiar la totalidad de su implementacion. Con accessors esta clase de cambios en general es trivial. Para resumir, el uso de accessors es una tecnica, y las tecnicas se deberian elegir mirando el costo de mantenimiento a futuro. En este sentido, para mi escribir y usar los accessors siempre me trae muchos mas beneficios (especialmente metabeneficios) que el costo que supuestamente los accessors puedan tener. Andres. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
