Zárate mira que te vas a partir el culo :-P, este fin de semana
después de muchas horas intentando entender las clases me decidí a
dejar los ejemplos de los libros y hacerme yo mi propia clase (que
valentía la mía), el caso es que el domingo a cosa así de las 23:00
la pruebo y me funciona... algo alucinante para mi.
Imaginad la felicidad que despertó en mi tal hecho ufff ... pero...
la felicidad no me ha durado ni una semana... va el Sr. Zárate y pone
un mail a la lista con las recomendaciones sobre lo que no se debe
hacer :-S.... y miro mi clase y están todas esas cosas que no deben
hacerse.
Os dejo mi clase para que la veáis y os riais un ratillo :-P, encima
las funciones de Over y Out no son mías, las saqué de un tutorial de
Manu Álvarez en Domestik. Que desastre.
P.D: Muchas gracias a todos por depositar en la lista vuestra
ilimitada sabiduría, los que nos quedamos en la sombra vamos
aprendiendo mucho con vuestras opiniones y consejos.
Re.PD: Si alguien ve que he hecho algo bien decídmelo y lo cambio...
me he propuesto hacer la peor clase de todas.
class clases.eventosBotones extends MovieClip{
public var seccionActual:MovieClip;
public var clip:MovieClip;
private function eventosBotones(){
//nombre de este clip
this.clip = clip;
//le asigno las funciones correspondientes a los eventos
this.onRollOver = function (){
Over(this);
}
this.onRollOut = function (){
Out(this);
}
this.onRelease = function (){
Release(this);
}
}
// función onRollOver para los botones
public function Over(clip) {
clip.onEnterFrame = function() {
clip.gotoAndStop(clip.nextFrame());
if (clip._currentframe == clip._totalframes) {
delete clip.onEnterFrame;
}
};
}
// función onRollOut para los botones
public function Out(clip) {
clip.onEnterFrame = function() {
clip.gotoAndStop(clip.prevFrame());
if (clip._currentframe == 1) {
delete clip.onEnterFrame;
}
};
}
//funcion Release
public function Release(clip) {
//Hago un trace del clip que hay antes de pulsar al botón
trace("Antes estaba pulsado el botón: " + _root.clipActual);
//activo el boton que este inactivo
_root.clipActual.enabled = true;
//devuelvo al botón a su estado inicial de reposo
Out(_root.clipActual);
//asigno al clip Actual el nombre de este clip para
poder activarlo despues
_root.clipActual = this.clip; //
desactivo el botón
this.enabled = false;
}
}
El 09/09/2006, a las 10:54, Joseba Alonso escribió:
> 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
> -----------------------------------------------------
-----------------------------------------------------
ASNativos
www.5dms.com
subscripciones/desubscripciones
http://asnativos.5dms.com
-----------------------------------------------------
