> Las subclases de Moviclip son muy interesantes a la hora de > aplicar los principios OOP a clases graficas. Las basicas: > Herencia, encapsulacion y polimorfismo.
Lamento discrepar, pero precisamente las clases gr�ficas son las menos indicadas para determinadas implementaciones, precisamente por ser eso, gr�ficos. > > Herencia: > Yo definiria, asi ,a bote pronto. Una subclase de MovieClip > abstracta, vamos a llamarla NaveBase que tubiera los metodos > b�sicos de movimiento, colocacion y destruccion del objeto. > De esta extenderia (subclasearia) una clase tambi�n > abstracta, MarcianoBase, con comportamientos comunes a todos > los marcianos, como la IA, y de esta, ya por ultimo, sacaria > las clases necesarias para los distintos enemigos: > MarcianoPeon, MarcianoChungo y MarcianoJefe, estas si que > podrian estar vinculadas con elementos de la biblioteca. > Estas 3 compartirian mucha funcionalidad que viene dada por > las clases base (NaveBase y MarcianoBase) con lo que ya > estarias ganando en cuanto a reutilizacion de codigo. En el > caso de escribir las funciones directamente sobre la linea de > tiempo probablemente tendrias que duplicar gran parte del > codigo de una a otra. Un cambio en una supondria la > modificacion del resto. Si necesitas nuevos tipos de > marcianos ya no comienzas de 0 sino que tienes una base de > codigo sobre la que partir (extender). Sin contar que podrias > utilizar el NaveBase tambi�n para extender la clase NaveHeroe. Veamos, asignar la responsabilidad de la inteligencia a un gr�fico, choca con uno de los conceptos que el mismo Joseba ha nombrado, el del acoplamiento, y otro que no ha nombrado, y con el cual el choque es a�n mayor, la cohesi�n ( el ejemplo m�s claro de baja cohesi�n, es una clase que hace demasiadas cosas, y muy dispares entre s� ). Siempre hay que intentar buscar el menor acoplamiento y la mayor cohesi�n posibles ( �ste es un concepto b�sico del dise�o orientado a objetos ), y eso no se va a lograr haciendo que una misma clase sea responsable de la inteligencia ( yo prefiero llamarlo comportamiento ), y de la representaci�n gr�fica. Por lo tanto, el implementar ciertas funcionalidades en un movieclip no es, por decirlo de alguna manera, una pr�ctica muy aconsejable, al menos en este caso. Dicho de otra forma, un marciano es un se�or de marte, no un movieclip. No se trata de que la herencia sea un recurso mejor o peor, sino que es un recurso que no hay que utilizar a toda costa, sino s�lo cuando realmente nos resuelva la papeleta. En este caso, todo ser�a mucho m�s facil si una �nica clase, que implementara un interfaz �nico, fuera la responsable de presentar los distintos tipos de marcianos. De esta manera, no necesitamos 4 clases con un huevo de c�digo heredado de la clase base, y que est� ah� s�lo por estar. En cuanto al resto de conceptos, son definiciones bastante claras y extendidas, est�n en cualquier libro de casi cualquier lenguaje de programaci�n actual, por lo que su utilidad no est� limitada, obviamente, al flash / actionscript. Espero que todo esto te sirva de ayuda. Cesar Tardaguila [EMAIL PROTECTED] ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ----------------------------------
