> > Bueno, primero decir que yo no soy un gran estudioso de las > artes de la ingenieria de programacion, de proyectos como los > que tu has mencionado (grandes-enormes-desmesurados). > B�sicamente por que soy un programador web, especializado en > RIAs. No soy (m�s quisiera) John Carmack Y jamas he > necesitado meterme en un proyecto de a�os con 10 > programadores m�s (ni siquiera se si me gustaria). Ese no es > mi ambito, ni creo que el de la gran mayoria de esta lista. > Asi que hablo desde mi punto de vista, puramente empirico. > Sin intencion de ofender a la L33T de la programacion OOP.
Lo siento, pero no entiendo eso de la L33T. De todas formas, yo pensaba que esta lista era para intercambiar opiniones, experiencias, y conocimiento sobre el actionscript. Lamento haberlo hecho. Obivamente yo tampoco soy el Sr Larman, pero eso no quita para que, con el tiempo, unas ca�as, y esfuerzo personal, pueda intentarlo. � O s� ? > IMHO cualquier cosa que yo tenga que representar en pantalla > *tiene* un modelo de datos, siempre, siempre, siempre. Porque > si no es asi simplemente voy y lo coloco en esa maravillosa > linea de tiempo que MM nos a proporcionado :). Ahora bien, > cuando dices "porque en este caso no hay una vista y un > modelo" no se a que caso en concreto te refieres, porque no > entiendo como puedes negar que en un juego matamarcianos > *hay* un modelo. De hecho, nunca he programado nada que no > tenga un modelo de datos, aunque este sea un simple Array. > Asi que en este punto no te entiendo muy bien. > Es my sencillo. La clase que controla el comportamiento de un marciano es un controlador. No el modelo. El modelo del juego ser�n las reglas del mismo ( recordemos: el modelo es la l�gica y datos de la aplicaci�n ). Por lo tanto, no niego que en un matamarcianos haya un modelo, simplemente te estoy discutiendo que lo que t� identificas como modelo, a m� me parece evidente que es un controlador ( el controlador del movieclip que representa al gr�fico del marciano ). > Ser� interesante. Pero en los 4 parrafos que siguen a este, > en lo que escribes, no logro dislumbrar una tecnica, ni un > metodo de trabajo para el desarrallo de un elemento con > entidad grafica (como tu lo has llamado). Solo veo verborrea > "de libro", no una solucion, ni una explicacion especifica > sobre el tema que estas intentando debatir. > Lamento que no vislumbres una t�cnica en la propia descripci�n de la t�cnica ( o la verborrea, como se quiera ). Ante eso, no puedo decir mucho, est� ah�, son cuatro conceptos b�sicos, no los puedo resumir m�s. Pero lo voy a intentar exponer de otra forma. No es bueno que haya clases que hagan demasiadas cosas y muy dispersas, no es bueno una herencia demasiado profunda, y es bueno desacoplar en lo posible las cosas ( y perd�n si sueno academicista ). > El metodo que yo utilizo de trabajo, en una RIA, en Flash, en > un proyecto "normal" (2 o 3 meses de trabajo de 1 o 2 > personas), es el de crear elementos de interface (asi los > llamo yo) cuya responsabilidad es la controlar los aspectos > de su representacion en pantalla. Ni m�s, ni menos. > Si creo un boton, este debe ser responsable de dibujarse en > pantalla, de poder cambiar de tama�o, color, notificar de > eventos como rollovers, clicks...ese tipo de cosas. Si esa > funcionalidad se comparte con m�s elementos graficos, utilizo > la herencia. Lo hago asi porque me parece que tiene m�s > sentido, me es m�s natural, me proporciona facilidad de > desarrollo y se integra con el framework existente por parte > de MM. Una vez m�s, creo que est�s mezclando churras con merinas. Me parece estupendo que te encante hacer RIAs. De hecho, lo que nadie te ha discutido, entre otras cosas por lo evidente que resulta, es que un bot�n es un movieclip. Y m�s evidente a�n que eso es que la funcionalidad compartida entre distintas clases deber�a moverse a una clase base de las que heredaran las otras. Eso no se ha discutido. Ahora bien, no todo en este mundo es colocar botones en pantalla y validar formularios. Por mil y una razones ( evoluci�n de la tecnolog�a, evoluci�n de la propia herramienta que utilizamos, crecimiento personal de cada uno, demandas del mercado ), �ltimamente nos empezamos a encontrar con que hay que sacar adelante proyectos mucho m�s complejos ( sobre todo desde el punto de vista arquitect�nico ) de lo que hasta ahora est�bamos acostumbrados. Y eso requiere soluciones que no siempre son las que hemos estado utilizando hasta ahora. > No digo que sea el nirvana del programador, sino que > es un metodo bastante sencillo de implementar, extensible y > aplicable inmediatamente al 100% del trabajo que yo realizo. > Conozco tu vision sobre esta tecnica, que discutimos > ampliamente hace unos meses, sobre "la maquina de estados" y > demas. La respeto. Porque como tu dices la libertad del > desarrollador a la hora de implementar esta fuera de toda > duda. Pero date cuenta que yo puedo pensar, como tu mencionas > de mi, que no estas planteando el problema desde el punto de > vista adecuado. Las m�quinas de estados ( sin comillas ) son un recurso que tampoco he inventado yo, sino que han sido y ser�n ampliamente utilizadas en muchos �mbitos ( simulaciones f�sicas, simulaciones de funcionamiento de maquinaria, juegos, etc ), y adem�s, es algo de lo que no recuerdo haber hablado en este hilo. Y por cierto, no son m�s que la implementaci�n de uno de los patrones de dise�o m�s utilizados ( el patr�n State, que es el patr�n de comportamiento por excelencia ). > Pero eso a quien cojones le importa, no creo que a nadie. Tu > has seguido tu logica y has obtenido el resultado que > esperabas, has tenido exito. Lo mismo puedo decir yo de la > mia. Es por esto, que conocidas las 2 tecnicas, veo > completamente inutil argumentar cual es la mejor, porque si > la tecnica que empleas ha satisfecho tus necesidades, es que > es correcta. A partir de ahi se convierte en "a ver quien la > tiene m�s grande". Algo que, seguro que coincimos, no aporta > ningun beneficio a nadie. Una vez m�s, creo que est�s entendiendo mal el objetivo de la discusi�n. Esto no va de "yo lo hago mejor que t�", sino que va de "esa soluci�n no es aplicable siempre", o "esa soluci�n no siempre va a ser la mejor". Por cierto, me alegra ver que has dado con la soluci�n extensible y aplicable para el 100% de los proyectos. S�lo me queda darte mi m�s sincera enhorabuena Un saludo, Cesar Tardaguila [EMAIL PROTECTED] ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ----------------------------------
