Unas cositas.. 1°, con referencia a lo que dijo pablo martín Viva, nunca dije lo contrario.. no se de donde salió todo eso que dijiste :S, digo porque creo que lo pusiste por el ejemplo de los frameworks que puse.. y era solo un ejemplo.. donde te obligaría a vos programador a olvidarte de la abstracción y demás, y poner todo publico, y apuntaba a eso, que justamente recalca que puede ser malo. No a que llenar todo de getters y setters en si sea malo, eso depende de cada problema en particular. obviamente eso te permite hacer chequeos, o manejar diferentes tipos de datos sin modificar la interfase, tiene muy buenos pros, como la mayor parte de las buenas costumbres..
2° no entiendo como salió a partir de un ejemplo tirado así sin pensar toda una discusión sobre getters y setters.. y sobre propiedades( para los que son mas filosóficos y piensan que es algo diferente, por no llevar paréntesis. Obvio, es cómodo, es mejor, en muchos casos, pero no es mas que ponerle un poco de maquillaje a algo común, y aparte, pasa a ser algo muchísimo mas restrictivo, ya que en general no le vas a poder pasar ningún parámetro.) 3° con respecto de lo que dijo Alberto Bertogli, sobre la escalabilidad de los sistemas por el hecho de no tener gettes o setters o de tenerlos.. yo realmente estoy seguro que cualquier sistema en principio puede ser escalable cualquiera fuese el lenguaje, y la forma de programar empleada.. ( osea con o sin getters y setters como ejemplo.) lo que no quita que haya sistemas mas escalables que otros, y eso tambien incluye, lenguajes mas escalables, y formas de programación mas escalables que otras. saludos y suerte ;) --- Pablo Martín Viva <[EMAIL PROTECTED]> escribió: > Yo no veo que el hecho de tener getters y setters > por todos lados sea malo, > sino que ademàs a los getters y setters hay que > darle su debida visibildad > sino no sirve. A mi me gusta para ser mas organizado > con mi codigo poner > getters y setters de todo por 2 razones, en los > getters puedo tener > validaciòn adicional para vlidar que el dato al que > voy a acceder es valido > o esta inicializado o lo que fuera y segundo que me > abstrae desde mi propio > codigo la representación interna que uso de mi > atributo... Obviamente que no > todos los getters y setters los voy a dejar > publicos, sino perderia la > absttracción, pero puedo dejarlos privados o > protegidos para que clases > derivadas puedan accederlos si es necesario y no > esten modificando datos de > forma arbitraria... > > Un caso valido para esta aplicación es si tengo un > dato que puede tomar > ciertos valores de rango si yo no tengo un getter / > setter aunque sea > privado o protegido nada me asegura que el valor que > yo le asigne sea el > correcto, yo eso lo puedo validar con un mètodo asi > y ademàs lanzar > excepciones en caso de que sea necesario hacerlo, > cosa que con acceder al > atributo directamente no puedo hacerlo. > > Entiendo que dejar todo publico esta mal, hasta > cierto punto porque se hace > cagadas por eso, pero tampoco tener metodos de > acceso a dichos atributos > hace que se programe mal, hay que saber usarlos como > todo. > > Saludos > Pablo > > El día 23/04/08, Nicolás Bello > <[EMAIL PROTECTED]> escribió: > > > > quiero agregarte algo mas.. > > > > no se cuantos programadores externos a la facultad > > conocerás.. (no hablo solo de nuestra facultad, > digo > > de aquellos que programan pero no tienen estudios > > universitarios), pero entre ellos la idea de un > dato > > privado, por ejemplo, no existe demasiado fuerte, > y en > > general lo ven como una cosa molesta. Es para > ellos > > que en general se lo hace privado, para la gente > que > > piensa que sabe programar y hace cagadas lindas, > por > > no poder respetar un minimo de acuerdo entre > > programadores. > > > > Porque digo esto, lo digo porque esos sistemas no > lo > > veo como algo que se hace únicamente para que > gente > > que no tiene idea programe( como bien podría ser > tu > > mamá por lo que dijiste.), sino mas bien, para que > los > > que programan y creen que saben hacerlo no se > manden > > cagadas.Digamos, creo que en principio ninguno de > > nosotros tendría que tocar un dato privado por mas > que > > tengamos forma de hacerlo simplemente porque > > entendemos que el dato es privado por algo, pero > > lamentablemente eso no aplica en todos los > > programadores. > > > > Creo que eso es el principio fundamental de porque > > existen. > > > > Yo personalmente veo que tiene sus pros y sus > contras, > > pros en que hace que la gente se mande menos > cagadas, > > y en general programe mejor... contra en que hace > que, > > como ,por ejemplo, existen frameworks que > necesitan > > los datos que son privados, necesitas tener > metodos > > getters y setters para todo, lo cual es lo mismo > que > > nada.. y le agrega una complejidad extra que no > tenia > > en un principio. > > > > en fin. espero que se entienda el punto. > > suerte ;) > > > > --- Marcos Medrano <[EMAIL PROTECTED]> > > escribió: > > > > > 2008/4/22 Leandro Lucarella <[EMAIL PROTECTED]>: > > > > > > > > Claro, justamente a lo que me refería es que, > de > > > una forma medio > > > > rebuscada, al final siempre termina siendo una > > > convención. Cuando yo pongo > > > > algo private en C++, es una forma de > > > documentación, de decirle al tipo que > > > > use mi clase "porfi, porfi, no te metas con > estos > > > atributos" (como cuando > > > > ponés un método que empieza con "_" en un > lenguaje > > > que no lo soporta). El > > > > lenguaje C++ provee una forma de decirlo > > > enfáticamente y trata de hacer > > > > algunos chequeos para ver que se cumpla. > > > > > > > > > Claro, esto sospechaba. > > > De todas maneras siento que es algo mas fuerte > que > > > una convencion. Si yo > > > "aviso" que no hay que usar tal cosa, y si > ademas > > > uso herramientas del > > > lenguaje para subrayar que no hay que usarlo.... > ya > > > no se puede proteger mas > > > al programador. Se fue notificado y advertido, y > que > > > se haga cargo, quien > > > acceda, de los problemas que aparezcan. > > > > > > En principio me parece que me gusta mas la idea > de > > > dejar las cosas "en manos > > > del programador". Considerando que uno debe > > > instruirse minimamente en lo que > > > usando y como lo va a usar. Hasta quiza eso > ayude a > > > tener un mejor producto. > > > Digo... tampoco es la idea de sentar a mi vieja > en > > > frente a... NetBeans y > > > preocuparme por hacerle la vida facil para que > > > programe. (o quizas si?). > > > Supongo que ayudaria a que uno preste mas > atencion a > > > lo que hace y, > > > consecuentemente, el producto salga un poco mas > > > robusto. Bah, son todas > > > suposiciones mias, quien sabe... no estoy del > todo > > > seguro de eso que digo. > > > > > > El tema de la complejidad, que vos mencionas > Carlos, > > > no lo habia tenido en > > > cuenta. Tambien puede ser una cosa que incline > un > > > poco la balanza. > > > Podria ser que por mas calificado que un > programador > > > este, se tenga que > > > enfrentar con sistemas bastantes complejos y sea > > > algo "util" implementar el > > > concepto de visibilidad. Tambien podria > considerarse > > > que un sistema no > > > deberia llegar a ser tan complicado. Un buen > > > analisis de los requisitos y > > > del diseño de un sistema quiza podria achicar un > > > poco las responsabilidades > > > del programador, dividiendo las partes del > sistema > > > en partes mas elementales > > > (divide y venceras?) y no tener que caer en > > > modificaciones del lenguaje... > > > > > > En fin... veo que en definitiva parece cuestion > de > > > poner cosas como estas en > > > la balanza y ver que convence mas a los que > deciden > > > el futuro del lenguaje > > > en cuestion. > > > > > > Saludos y gracias por las respuestas! > > > > > > Marcos. > === message truncated ===> _______________________________________________ > Lista de correo Programacion. > [email protected] > http://listas.fi.uba.ar/mailman/listinfo/programacion > Tarjeta de crédito Yahoo! de Banco Supervielle. Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. www.tuprimeratarjeta.com.ar _______________________________________________ Lista de correo Programacion. [email protected] http://listas.fi.uba.ar/mailman/listinfo/programacion
