Una clase puede implementar * interfaces; esta pseudoherencia múltiple es muy útil. Pese a que estoy de acuerdo contigo en la comparación entre herencia y composición creo que en el caso de la herencia de MovieClip es un tema bastante más controvertido. Aparte de lo ya comentado:
- Los MovieClips siempre serán vistas y en muy pocas ocasiones necesitaremos extender la funcionalidad de los MovieClips. El manido ejemplo de "acelerar()" o "disparar()" para que un MovieClip haga "algo" tiene más sentido a nivel de modelo. Comodidad aparente. - Un buen diseño debería favorecer el control de vistas. Utilizando múltiples instancias de una subclase de MovieClip obligamos a que la responsabilidad de la vista sea exclusivamente de cada MovieClip en particular. Aunque muy cómodo también, no es ni lo más idóneo ni lo más escalable. - Para que una instancia persista es necesario que esté presente en el Stage. Y como siempre que tenemos un hilo con este subject, habrá gente que prefiera favorecer la "comodidad" y gente que opte por un diseño más escalable. Cuantas más opciones, mejor. M. -----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 -----------------------------------------------------
