Es evidente que la discusi�n inicial ( sobre los beneficios de la OOP ) ha derivado a otra discusi�n distinta ( sobre un OOD apropiado ).
En ese marco, y sin �nimo de seguir machacando la discusi�n, creo que Joseba no est� planteando el problema desde un punto de vista apropiado. No se trata de separar vista y modelo ( lo cual, como todo el que haya le�do alg�n libro de OOP un poco avanzado sabe ), porque en este caso no hay una vista y un modelo. De lo que se trata es de decidir d�nde deben residir las responsabilidades del comportamiento de una entidad con representaci�n gr�fica. Por lo tanto, aunque parece que por fin estamos de acuerdo en no implementar ciertos comportamientos complejos en un movieclip, me temo que no lo estamos por los mismos motivos, y eso es algo que me interesa aclarar. La asignaci�n de responsabilidades es el punto clave, m�s complejo, y que requiere mayor grado de racionalidad, intuici�n, visi�n global de la arquitectura, y conocimiento de una serie de reglas b�sicas de todo desarrollo de un tama�o que sobrepase las media docena de clases. Gente con mucha m�s experiencia que cualquiera de nosotros ( no s�lo en a�os de profesi�n, sino en desarrollo de proyectos grandes-enormes-desmesurados ) hace tiempo que manejan una serie de normas a la hora de decidir qu� debe hacer cada clase. La fundamental, el sentido com�n, pero aparte de eso, los llamados patrones GRASP que son uno de los pilares, por ejemplo, del Proceso Unificado ( m�todo de desarrollo centrado en la arquitectura, iterativo e incremental, germen de algunas de las metodolog�as del XP ). Por resumir, los cuatro patrones GRASP principales son: bajo acoplamiento ( debe haber pocas dependencias entre clases, por lo que no es bueno, por ejemplo, que haya una herencia muy profunda ), alta cohesi�n ( cada clase debe realizar una labor �nica y perfectamente identificable, por lo que no es bueno, por ejemplo, que una clase haga demasiadas cosas ), controlador ( el flujo de eventos se asigna a clases espec�ficas, aunque no es bueno que tengan demasiadas responsabilidades ) y experto ( asignar la responsabilidad de realizar una acci�n a la clase que tiene todos los datos para hacerlo ). Aparte de eso cuatro patrones principales, hay otros, como el polimorfismo, la indirecci�n, las factor�as, y mi preferido: "nunca hables con extra�os". Por tanto, aunque la libertad del desarrollador a la hora de implementar las soluciones que su problema requiere est� fuera de toda duda, no nos conviene olvidar que existe una metodolog�a que nos da una serie de herramientas para llegar a implementar esas soluciones. Y que esas herramientas han sido fruto de los a�os de experiencia y del talento de muchos y muy buenos desarrolladores. Cesar Tardaguila [EMAIL PROTECTED] > -----Mensaje original----- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de Joseba Alonso > Enviado el: mi�rcoles, 08 de septiembre de 2004 20:57 > Para: [EMAIL PROTECTED] > Asunto: Re: [ASNativos] movieclips subclases > > Manu, Cesar... > > Como decia en un email anterior, anexo al que mencionais, la > explicacion era sobre las ventajas del uso del OOP sobre una > implementacion procedural en el marco de los movieclips. > Entendi mal la pregunta de Pedro. Los ejemplos estaban > pensados para que alguien entendiese dichas ventajas, no era > una vision composicion vs herencia vs agregacion. Tampoco > eran una exposicion especifica sobre los beneficios de la > herencia frente a otras relaciones entre objetos. Entendi que > no comprendia las ventajas de usar subclases en vez de > colocar el codigo en la linea de tiempo del movieclip (a trav�s de > funciones) y usar un codigo centralizado para la gestion de > todo (1000 lineas de codigo en la linea de tiempo de _root). > > Efectivamente la implementacion de tal sistema pasaria por > separar el modelo de la vista, como cualquiera que sepa OOP > podria deducir. Aunque yo personalmente seguiria usando una > subclase de movieclip para los marcianos, que controlase su > apariencia grafica y su comportamiento como elemento grafico, > que hacer una composicion con wrappers de metodos de MC. > Logicamente la IA es el modelo, que iria fuera de esa > subclase, entre otras cosas. Pero esto ya es una opinion > personal, algo que ya discutimos acaloradamente hace algun > tiempo. No veo el sentido de volver a discutirlo de nuevo. > > un saludo > > Joseba Alonso > www.sidedev.net > www.5dms.com > > > ---------------------------------- > Lista ASNativos:[EMAIL PROTECTED] > http://www.5dms.com/listas > ---------------------------------- > ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ----------------------------------
