Desde una postura m�s inductivista que implementacional tambi�n se llega
a la misma conclusi�n de que un marciano no es un MovieClip. Y es que
aparte de que tenga baja cohesi�n y alto acoplamiento, una clase debe
ser f�cilmente racionalizada.
Desde este punto de vista es mucho m�s asimilable el considerar un
objeto Marciano que tiene una representaci�n gr�fica, que no es
aut�noma, y se agrega a la clase Marciano --�para qu� necesitamos un
Marciano que haga loadMovies?--.
Como tambi�n tendremos diferentes tipos de elementos gr�ficos que sigan
el mismo esquema, podemos utilizar una interfaz para este polimorfismo
(EnemigoIF, por ejemplo).
A la hora de determinar cu�l es la relaci�n contractual entre dos clases
es importante tener en cuenta que:
- la agregaci�n ("uses-a") consiste en utilizar otras clases para una
determinada acci�n. i.e.: la relaci�n que existe entre un coche y un
garaje
- la composici�n ("has-a") consiste en a�adir instancias de clase dentro
de nuestra clase (se destruir�n al destruir la clase). i.e.: la relaci�n
que existe entre un coche y la caja de cambios.
- la herencia ("is-a") extiende la funcionalidad y/o la estructura de
una superclase. i.e.: la relaci�n que existe entre un coche y un medio
de transporte.
En ning�n momento he considerado (C�sar creo que tampoco) el uso de
composici�n para la representaci�n de una clase del tipo "Marciano", en
ese caso la relacci�n "natural" ser�a de agregaci�n.
M.
----------------------------------
Lista ASNativos:[EMAIL PROTECTED]
http://www.5dms.com/listas
----------------------------------
