si, por eso yo siempre digo que subclasificar para reutilizar código no es bueno, hay que evitarlo, no está hecho para eso, sin embargo es como más se usa lamentablemente. Los prototipos tienen muchas ventajas, se ve en la implementación de algunos patrones como decorator, adapter, etc (wrappers) pero también algunas falencias como la organización...
Un abrazo Hernan 2011/2/28 Andres Valloud <[email protected]> > Jaja, no... > > 2011/2/28 Hernan Wilkinson <[email protected]>: > > che Andres, me parece que agarraste para los tomates :-) por lo menos yo > no > > dije que las clases no servían ni que la subclasificación tampoco... es > más > > en el 2 punto digo que al final las clases son necesarias sino queda todo > al > > mismo metanivel y eso también es confuso... y como toda herramienta, > puede > > ser buena o mala según como se la use. No entiendo porque decís que "hay > que > > sacarlas". > > Capaz que lo dije no tan claro... lo que quise decir es que cada tanto > comentas que a veces es dificil conseguir subclasificaciones buenas, y > que es comun (o por lo menos no sorprendente) encontrarse con ejemplos > medio bizarros de subclasificaciones. Me quedo la idea de que tambien > puede ser dificil de enseñar algun criterio facil para subclasificar > bien. > > Bueno, suponiendo que hayas dicho eso :)... a lo que iba es que si es > relativamente facil encontrar casos donde se subclasifica mal, me da > la impresion de que hay argumentos del estilo "como se subclasifica > mal en general, la culpa es de las clases" en vez de "como se > subclasifica mal en general, entonces programamos mal en general". > Bueno, entonces cada tanto sale alguien a dar alternativas a las > clases, como por ejemplo "las clases son un error historico, y por lo > tanto hay que usar prototipos". Si, bueno... pero como dijeron otros > por aqui, la opinion un poco mas constructiva tambien vale. > > Por ejemplo, porque en general se subclasifica mal? A mi me da la > impresion de que hay dos factores... por un lado esta el manejo de > responsabilidades como fuerza antagonista a querer ahorrar escribir > hasta el ultimo metodo posible. Como ilustracion: Dictionary como > subclase de Set aunque la conducta es bastante diferente. O si no, > poner FilaDeAlumnosDeLaPrimaria como subclase de SortedCollection y > con el sortBlock por default reimplementado para hacer [:x :y | x > altura <= y altura]. > > El otro factor es la facilidad de cambio. Cuando considerar el > mantenimiento a futuro de las cosas no tiene tanta prioridad como > otras cosas, entonces aparecen objetos con 20 variables de instancia > (me acuerdo de algunos trabajos anteriores) o miles de metodos > (Morph). Con un poco de subclasificacion o composicion+delegacion, > esos problemas desaparecen. Lo que si es cierto es que diseñar esas > cosas a largo plazo lleva bastante mas tiempo que poner mas variables > de instancia y metodos para resolver el problema urgente que tiene que > estar resuelto para hoy a la tarde. > > Hay soluciones para estos lios, desde ya. Que otros problemas tienen > las clases? Y como se resuelven con prototipos? Que caracteristicas > de mantenimiento a largo plazo tienen las soluciones de los problemas > de las clases hechas de manera equivalente en prototipos? > > 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 > -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [email protected] site: http://www.10Pines.com <http://www.10pines.com/>* -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
