Andres, te contesto en partes: On Jun 5, 8:27 pm, Andres Valloud <[email protected]> wrote: > 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...
Estamos de acuerdo, un proyecto no se termina nunca. Me encantaría que convenzas a mis clientes de esto :-). Lo que quise decir y tal vez no me salió es que en si existen frameworks, como el de Dolphin, para extirpar los métodos de das como ejemplo, son un indicador de que hay momentos para que existan dichos métodos y momento para que no existan. Y lo mismo pasa para cualquier método. > > > 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. No entiendo lo de "nivel meta mas elevado". > Ejemplos tipicos... encontrar > objetos rotos con allInstances select: [:x | x talVariable talCosa]. > Sin accessors, imposible. Si se trata de reparar un image, entonces vale todo, incluso poner termpoarlmente #talVariable en Object y luego sacarlo. >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. Pero en ese caso es cantado que dichos mensajes tenían senders. > Para resumir, el uso de accessors es una tecnica, y las tecnicas se > deberian elegir mirando el costo de mantenimiento a futuro. Adoptar una técnica tan amplia puede ser caro en el futuro. El image de Smalltalk ya ronda los 30 años y su 5 iteración, si tener accessors fuera algo tan necesario ya vendrían puestos, incluso a nivel VM. Son muy usados y útiles pero no como para levantar una bandera a favor de ellos :-). >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. Metabeneficios? (interpreto como beneficio de los beneficios y no te entiendo, disculpas). Pongo un ejemplo de mal uso que yo hago de accessors: Tengo una serie de frameworks de persistencia, GUIs, reportes, etc... algunos de ellos acceden a los objetos a través de accessors. Con el tiempo me doy cuenta que tengo muchos objetos muy simples, llenos de accessors solo porque dichos frameworks los necesitan, y en algunos casos (como en la persistencia) si sería correcto acceder directamente a las variables de instancia o delegar en el objeto la resolución. Tener dichos accessors molestan especialmente al hacer refactorings, ya que sabemos que cualqueir Refactoring Browser no puede resolver bien esos aspectos (por suerte). DiegoCoronel>>saludos "Returns the receiver's instance variable saludos" ^saldos DiegoCoronel > 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 -~----------~----~----~----~------~----~------~--~---
