Nahuel: Me refiero a views. A las vistas de los modelos. Las vistas estan compuestas o armadas con "componentes" visuales. Al no permitir manipular o acceder desde afuera a los subcomponentes evitamos problemas de dependencias entre vistas (esto ocurre cuando alguien labura mal, hay que reconocerlo). Al evitar estas dependencias garantizamos un alto porcentaje de reuso de esas partes visuales para componer otras más refinadas.
Lo mas importante con respecto a esto setters y getters (discusion interminable) es buscar los casos donde realmente las ventajas superan al costo de mantener los accesos a las variables en forma directa. (Este costo hoy es más bajo gracias al Refactoring Browser). Muchas veces tratamos de ser más elegantes que las mismas implementaciones. Por ejemplo, considero Dolphin Smalltalk una de las más elegantes y ordenadas y sin embargo en la definicion de Presenters (views) utilizan todo el tiempo el acceso directo a las variables, es un PATTERN para esas clases. La uniformidad en el cumplimiento del pattern es importante tambien, por ejemplo, en la jerarquía de Presenter, estoy seguro que para todos los subcomponentes uso v.i. sin accessors. No es que esté a favor de una u otra cosa sólo me importa restarle tanta trascendencia. Saludos GallegO El 3 de junio de 2009 9:58, Nahuel Silva <[email protected]> escribió: > > > 2009/6/3 GallegO <[email protected]> > >> Nahuel: >> >> Aca tenemos la regla que en el caso de los Presenters (views) no definimos >> accessors a las variables de los mismos. De esa manera cortamos con la >> posibilidad de manipulación externa de cuajo. Si ya se, podes ponerlos como >> privados pero es dificil detectar el envio de privados. > > No sabría si es dificíl detectar el envío de privados, habría que > preguntarle a Andres....y veo que ahí le acabás de preguntar :). > Se ve bien lo que decís respecto de los presenters, aunque no me gusta eso > de que no haya accesors (jajaja) pero bueno :). > >> >> >> De esta forma construimos partes visuales que tratamos como componentes. > > No entiendo. Te referís a partes visuales que después vos "agregas" a tu > modelo ? MiClasse addComponent: aVisualPart? jajaja Lo de tratarlos como > componentes no me cierra. > >> >> >> Por el resto, definimos accessors para todo, sólo ponemos algunos peros en >> algunas variables como caches, o algun estado que queramos proteger de >> manipulacion externa, aunque sea por accidente. > > > Piola lo de los caches también. > >> >> >> Saludos >> GallegO > > > Saludos, gracias > > Nahuel > >> >> >> El 2 de junio de 2009 16:46, Nahuel Silva <[email protected]>escribió: >> >>> 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 -~----------~----~----~----~------~----~------~--~---
