Vaya hombre, con las ganas que tenia, y vaya dia me pegao... En fin ... Que a mi me gusta extender de MovieClip xDDDDDDDD
Ahora en serio, ya se ha posteado mucho y bueno sobre el tema en lo que va de día, y estoy de acuerdo con Julio, no creo que sea un "delito" extender de MovieClip, a mi personalmente me es comodísimo en ciertas circunstancias, y como bien comentaba tambien Julio, el problema esté en el abuso tanto de composicion como de herencia, y que decir tiene, que claro, se aprende programando y por ende , "cagandola", como lo he hecho muchas veces ( y seguro que lo haré muchas mas ... ). Yo soy diseñador, y para mí flash fue inicialmente una herramienta gráfica basicamente, que te daba total libertad para diseñar, disponer elementos, etc... Tener un clip en tiempo de diseño, al que puedas asignar los comportamientos deseados, me parece la caña. En combinacion además con otros patrones, resulta muy útil, no se, por decir, a mi me es mucho mas comodo que un view de un MVC extienda de movieclip, me parece muchisimo mas facil que hacerte un view a base de codigo ... Y si para colmo usas compos made in MM ( si yo los uso xDD )( re-flamer!! ), ya te cagas con el code. En cuanto a los interfaces, yo curro solo, y no puedo vivir sin ellos !! Como bien dice Manu, unos tiraran por "comodidad" y otros por "escalabilidad", todo depende del proyecto que tengas entre manos, tiempo, presupuesto, ganas y demas circunstancias, si merece la pena, se mira por la "escalabilidad" y si no, pues a la comodidad !! Salu2! El 8/9/06 22:39, "Manuel de la Higuera" <[EMAIL PROTECTED]> escribió: > 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 > ----------------------------------------------------- > ----------------------------------------------------- ASNativos www.5dms.com subscripciones/desubscripciones http://asnativos.5dms.com -----------------------------------------------------
