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
