No se que nos pasa pero siempre que sale un tema "profundo" de estos en la lista los animos se exacerban. Es una conversacion muy interesante, sobre todo para mucha gente en la lista que quieren entender todo esto, que son los que no estan escribiendo nada pero esperando aprender mucho de la gente que si sabe y utiliza POO. Asi que os animo a seguir con esta conversacion pero tened en cuenta por favor un par de cosas.
La POO es un poco como la religion de los programadores, por favor hay que tratarla desde la humildad de lo que sabe cada uno, todo el mundo puede equivocarse con un termino, se corrige amablemente y no pasa nada, todos aprenden más. Todo lo que ha dicho Dani en su primer mail estaa muy bien, aunque ciertamente ha confundido el polimorfismo con la sobrecarga. Pero son dos palabros, nada mas. Hay mucha terminologia en la POO, es facil equivocarse, no pasa nada, a mi, por ejemplo, me pasa muchas veces. Cada uno tiene un punto de vista sobre como debe aplicarse, los hay mas puristas, mas relajados, seguidores de la herencia de MovieClip y detractores...etc. Lo bueno de POO es que tiene mucho de "filosofia", de tomar unos conceptos y aplicarlo a como entiendes tu la organización de tu proyecto. Pero por favor, humildad, si no estais de acuerdo con el punto de vista de una persona simplemente exponed el vuestro, pero sin entrar en descalificaciones ni en un tono de superioridad. Todo el mundo cree estar en posesion de la verdad muchas veces cuando la verdad absoluta no existe. No repitamos los errores del pasado (http://www.mail-archive.com/[email protected]/msg01458.html), yo aprendi eso en su momento. Si conseguimos tener estas conversaciones sin que nos demos de tortas esta lista puede dar un paso evolutivo muy importante y que muchos estamos esperando desde hace tiempo. Asi que por favor, seguid con estos temas, pero con respeto y humildad :) Un saludo, Joseba > -----Mensaje original----- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de Julio > Rabadán González > Enviado el: viernes, 08 de septiembre de 2006 18:46 > Para: Lista dedicada a Actionscript > Asunto: Re: [ASNativos] heredar de movieClip > > [EMAIL PROTECTED] escribió: > > pues ya q estamos,y a raiz de los comentarios de zarate: > > > > - pq no heredar de movieClip, q tiene de malo???? > > - es recomendable usar interfaces cuando solo hay una persona > > trabajando en el proyecto? > > > > un saludo > > > > > > > > ----------------------------------------------------- > > ASNativos > > www.5dms.com > > subscripciones/desubscripciones > > http://asnativos.5dms.com > > ----------------------------------------------------- > > > > > > > > > Desde mi punto de vista no tiene nada de malo. Que no tenga > herencia múltiple flash no me parece una restricción, quizás > pueda alguien argumentarlo con un ejemplo (c# tampoco la > tiene y va de lujo). > Utilizarlo la herencia de MC para enriquecerlo, haciendo que > tus MC en escena se comporten de manera especial, me parece > de lo más útil. Que no "puedas" hacer un "new" (yo tengo un > articulo por ahí explicando como hacerlo, aunque usa código > no oficial), es algo que en breve dejara de ser un > impedimento ya que AS3 si te lo permite. Y siempre puedes > aplicar tu clase a un objeto de la biblioteca, siempre que > realmente sea lo que haya que hacer... > > El debate HERENCIA-COMPOSICIÓN: Cada cosa para lo suyo. Si > quieres crear un sistema de abstracto, que te ahorrará mucho > código repetido, vas a tener que heredar. Y componer es > genial para crear objetos ricos y sencillos de utilizar. > > Problemas: > > De heredar: es difícil en general, porque abstraer lo es. > O lo dominas o la vas a cagar estrepitosamente. Debes tener > muy claro por qué lo haces, tener un diseño que así lo exija. > Nada de heredar de buenas a primeras todo lo que se parezca, > y de aquella manera. Te vas a montar un árbol de clases > infinito y enrevesado, que solo tu entiendes y sirve pa poco > más que para usarlo en navidad con una estrella y bolitas de > colores. Mañana cambian los requisitos, y tu maravillosa > abstracción infinita mal diseñada no sirve para nada, y te > pegas 800 horas cambiado código en todas tus clases hijas > > De componer: es demasiado fácil. Enriquecer encapsulando > tiene sus lugares y ocasiones, pero abusar va en contra de la > sencillez (y del KISS). Debes producir mucho código, con el > consiguiente gasto de tiempo, que debe estar muy justificado. > Tiene el riesgo de que, al ser demasiado sencillo de hacer, > te lances a escribir sin pensar. Cuando te das cuenta has > escrito muuuchas lineas de código de algo ma-ra-vi-llo-so. > Algo maravilloso que con herencia podría haberse resuelto con > 10 veces menos código y el consecuente tiempo, claro que > pensando un poco más (y eso a veces duele). Y además tus > clases compuestas sirven en unos escenarios determinados, no > son tan flexibles como tus clases abstractas. > > Estoy acostumbrado a programar en equipos de 3 o 4 > personas, y he sufrido tanto los diseños con exceso de > composición como los que tiene exceso de herencia (incluido > los mios). Ambos son igual de dolorosos. > Creo que cada uno debe descubrir esto por si mismo, ya que no > hay formulas magistrales, y siempre que llegue el caso hay > que plantearse si heredar o componer. Si no lo tienes muy > claro, mejor compones. A lo mejor te equivocas, pero el mal > será menor. Heredar suele significar que la clase que has > diseñado antes has de modificarla, así que no te asustes si > ves que tu nueva decisión de diseño hace que deshagas camino > andado. Puede que este nuevo camino sea mucho mas llano y > divertido que el pedregal donde tes estabas metiendo. > > Esto se aprende programando y diseñando mucho. Así que al lío. > > Interfaces. Si alguien te ha dicho que los usos de las > interfaces es solo para grupos, no se enteró bien en su día. > Muchos patrones de diseño utilizan interfaces, y no > precisamente por el número de gente que los utilice. Aplicar > interfaces es otra manera de abstraer. Hacer que algo sea > noseque-able, ("tiene un..." y no "es un..."), con lo que te > ahorras tela de código (if...). también te solucionan > problemas que se resolverían con herencia múltiple, cuando > esta haga falta. Las clases abstractas son una maravilla, > pero si te hacen falta varias para una clase, mejor usas interfaces. > > Lo dicho, a diseñar y programar. > > ----------------------------------------------------- > ASNativos > www.5dms.com > subscripciones/desubscripciones > http://asnativos.5dms.com > ----------------------------------------------------- > > ----------------------------------------------------- ASNativos www.5dms.com subscripciones/desubscripciones http://asnativos.5dms.com -----------------------------------------------------
