INTRODUCCIN A LA POO

QU ES LA POO? Las siglas POO se corresponden con Programacin Orientada a Objetos, aunque muchas veces las podemos encontrar escritas en ingls OOP (Object Oriented Programming). En este primer captulo de este curso vamos a tratar de explicar de forma sencilla los principales conceptos y trminos que se utilizan dentro de este tipo de programacin, es decir, dentro de la Programacin Orientada a Objetos. No vamos a entrar en sesudas divagaciones filosficas respecto a la POO, sino que vamos a definir lo ms claramente posible cada uno de los elementos clave que aparecen en la POO para despus poder utilizarlos desde el lenguaje Java. Este captulo es muy necesario debido a que el lenguaje Java, como veremos en el siguiente captulo, es un lenguaje que se basa en la Programacin Orientada a Objetos, por lo tanto para conocer el lenguaje Java, es necesario conocer la Programacin Orientada a Objetos. La Programacin Orientada a Objetos trata de utilizar una visin real del mundo dentro de nuestros programas. La visin que se tiene del mundo dentro de la POO es que se encuentra formado por objetos. Para comprender bien la POO debemos olvidar un poco la Programacin Estructurada, que si nos fijamos bien es algo artificial, la POO es una forma de abordar los problemas ms naturales. Aqu natural significa ms en contacto con el mundo real que nos rodea, de esta
Pgina 1 de 19

forma si queremos resolver un problema determinado, debemos identificar cada una de las partes del problema con objetos presentes en el mundo real. En esta definicin de POO ya estamos haciendo referencia al elemento clave de la misma: el objeto. El objeto va a ser la modelizacin de los objetos que nos encontramos en el mundo real, estos objetos los vamos a utilizar en nuestros programas para dar la solucin al problema que nos ocupe en cada caso. OBJETOS Como ya hemos adelantado un objeto es la pieza bsica de la POO, es una representacin o modelizacin de un objeto real perteneciente a nuestro mundo, por ejemplo, podemos tener un objeto perro que represente a un perro dentro de nuestra realidad, o bien un objeto factura, cliente o pedido. Los objetos en la vida real tienen todos dos caractersticas: estado y comportamiento. El estado de un objeto viene definido por una serie de parmetros que lo definen y que lo diferencian de objetos del mismo tipo. En el caso de tener un objeto perro, su estado estara definido por su raza, color de pelo, tamao, etc. Y el comportamiento viene definido por las acciones que pueden realizar los objetos, por ejemplo, en el caso del perro su comportamiento sera: saltar, correr, ladrar, etc. Si tomamos un ejemplo que tiene que ver ms con el mundo de la informtica se pueden ver ms claros estos dos conceptos. Si tenemos un objeto pantalla que representa la
Pgina 2 de 19

pantalla de nuestro ordenador, el estado de la misma estara definido por los siguientes parmetros: encendida o apagada, tamao, resolucin, nmero de colores, etc.; y su comportamiento podra ser: imprimir, encender, apagar, etc. Los parmetros o variables que definen el estado de un objeto se denominan atributos o variables miembro y las acciones que pueden realizar los objetos se denominan mtodos o funciones miembro, y para indicar variables miembro y funciones miembro se utiliza el trmino general miembro. Si lo comparamos con la programacin estructurada los atributos o variables miembro seran variables y los mtodos o funciones miembro procedimientos y funciones. A partir de ahora y a lo largo de todo el curso vamos a utilizar nicamente la nomenclatura de atributos y mtodos. Los atributos de un objeto deben encontrarse ocultos al resto de los objetos, es decir, no se va a poder acceder directamente a los atributos de un objeto para modificar su estado o consultarlo. Para acceder a los atributos de un objeto se deben utilizar mtodos. Es decir, los mtodos exponen toda la funcionalidad del objeto, mientras que los detalles del estado interno del objeto permanecen ocultos. Incluso algunos mtodos tambin pueden permanecer ocultos. El hecho de ocultar la implementacin interna de un objeto, es decir, como est construido y de que se compone se denomina encapsulacin. La encapsulacin es uno de los beneficios del paradigma de la Programacin Orientada a Objetos. Normalmente un objeto ofrece una parte pblica que
Pgina 3 de 19

ser utilizada por otros objetos para interactuar entre s, pero tambin permanece una parte oculta para encapsular los detalles de la implementacin del objeto. Ya se ha dicho que un objeto est compuesto de atributos y mtodos. Como la caja negra de un avin, el objeto recubre la informacin que almacena y solamente podemos obtener la informacin e indicarle que realiza acciones por medio de lo que comnmente se denomina interfaz del objeto. Los datos y la implementacin queda oculta a los dems objetos que interaccionan en el programa, lo que favorece enormemente la proteccin de los datos y las estructuras internas contra las modificaciones externas al objeto. De este modo es mucho ms sencillo localizar errores en los programas puesto que cada objeto est altamente especializado, y slo se encarga de su tarea. Como se puede observar, esto consigue una mayor modularidad, que facilita adems el diseo en equipo de programas y la reutilizacin de clases (componentes) creados por otros desarrolladores. Hemos indicado que la encapsulacin es un beneficio que nos aporta la POO, es un beneficio porque permite abstraernos de la utilizacin de los objetos, es decir, a mi me interesa realizar una determinada tarea con un objeto (por ejemplo imprimir una pantalla o rellenar una factura), pero a m no me interesa como realiza este proceso internamente el objeto que estoy utilizando. En este momento entra en juego otro concepto importante de la POO y que es la abstraccin. La abstraccin indica la capacidad de ignorar determinados aspectos de la realidad con el fin de facilitar la realizacin de una tarea. Nos permite ignorar aquellos aspectos de la
Pgina 4 de 19

realidad que no intervienen en el problema que deseamos abordar, y tambin nos permite ignorar los aspectos de implementacin de los objetos en los pasos iniciales, con lo cual slo necesitamos conocer qu es lo que hace un objeto, y no cmo lo hace, para definir un objeto y establecer las relaciones de ste con otros objetos. Un objeto lo podramos representar como dos circunferencias, una interna que permanece oculta al mundo exterior y que contendra todos los detalles de la implementacin del objeto, y otra circunferencia concntrica externa, que representa lo que el objeto muestra al mundo exterior y le permite utilizar para interactuar con l. En la figura 1 se puede ver dicha representacin. La encapsulacin ofrecida a travs de objetos tienen varios beneficios, entre los que destacan la modularidad y la ocultacin de la informacin. Mediante la modularidad podemos escribir cdigo de manera independiente de cmo se encuentren construidos los diferentes objetos que vamos a utilizar. Y ocultando la informacin se permite realizar cambios en el cdigo interno de los objetos sin que afecte a otros objetos que los utilicen o dependan de ellos. No es necesario entender la implementacin interna de un objeto para poder utilizarlo.
Figura 1

Pgina 5 de 19

MENSAJES Los mensajes son la forma que tienen de comunicarse distintos objetos entre s. Un objeto por s slo no es demasiado til, sino que se suele utilizar dentro de una aplicacin o programa que utiliza otros objetos. El comportamiento de un objeto est reflejado en los mensajes a los que dicho objeto puede responder. Representan las acciones que un determinado objeto puede realizar. Un mensaje enviado a un objeto representa la invocacin de un determinado mtodo sobre dicho objeto, es decir, la ejecucin de una operacin sobre el objeto. Es la manera en la que un objeto utiliza a otro, el modo en el que dos objetos se comunican, ya que la ejecucin de ese mtodo retornar el estado del objeto invocado o lo modificar. Los mensajes se utilizan para que distintos objetos puedan interactuar entre s y den lugar a una funcionalidad ms compleja que la que ofrecen por separado. Un objeto lanzar o enviar un mensaje a otro objeto si necesita utilizar un mtodo del segundo objeto. De esta forma si el objeto A quiere utilizar un mtodo del objeto B, le enviar un mensaje al objeto A. Para enviar un mensaje se necesitan tres elementos: el objeto al que se le va a enviar el mensaje, el nombre del mtodo que se debe ejecutar y los parmetros necesarios para el mtodo en cuestin.

Pgina 6 de 19

CLASES Una clase es un molde o prototipo que define un tipo de objeto determinado. Una clase define los atributos y mtodos que va a poseer un objeto. Mediante las clases podremos crear o instanciar objetos de un mismo tipo, estos objetos se distinguirn unos de otros a travs de su estado, es decir, el valor de sus atributos. La clase la vamos a utilizar para definir la estructura de un objeto, es decir, estado (atributos) y comportamiento (mtodos). La clase es un concepto abstracto que generalmente no se va a utilizar directamente en nuestros programas o aplicaciones. Lo que vamos a utilizar van a ser objetos concretos que son instancias de una clase determinada. La clase es algo genrico y abstracto, es similar a una idea. Cuando decimos piensa en un coche todos tenemos en mente la idea general de un coche, con puertas, ruedas, un volante, etc., sin embargo cuando decimos "ese coche que est aparcado ah fuera", ya se trata de un coche determinado, con una matrcula, de un color, con un determinado nmero de puertas, y que podemos tocar y utilizar si es necesario. Sin embargo como ya hemos dicho la clase es la idea que define al objeto concreto. Un ejemplo que se suele utilizar para diferenciar y relacionar clases y objetos es el ejemplo del molde de galletas. El molde para hacer galletas sera una clase, y las galletas que hacemos a partir de ese molde ya son objetos concretos creados a partir de las caractersticas definidas por el molde.
Pgina 7 de 19

Una vez implementada una clase podremos realizar instancias de la misma para crear objetos que pertenezcan a esa clase. Las clases ofrecen el beneficio de la reusabilidad o reutilizacin, utilizaremos la misma clase para crear distintos objetos. Y luego veremos que una vez que tenemos una clase podremos aprovecharla heredando de ella para complicarla o especializarla para una labor concreta. Si comparamos las clases y objetos de la POO con la programacin estructurada tradicional, se puede decir que las clases son los tipos de datos y los objetos las variables de esos tipos de datos. De esta forma si tenemos el tipo entero, en la POO diramos que es la clase entero, y si tenemos una variable de tipo entero, en la POO diramos que tenemos un objeto de la clase entero. HERENCIA La herencia es un mecanismo mediante el cual podemos reutilizar clases ya definidas. Es decir, si tenemos una clase botn que define un tipo de objeto que se corresponde con un botn que tiene un texto, que se puede pulsar, etc., si queremos definir una nueva clase llamada botn de color, no tenemos que reescribir todo el cdigo y crear una clase completamente nueva, sino lo que haremos ser heredar de la clase botn, utilizar lo que nos ofrezca esta clase y aadirle lo que sea necesario para la nueva funcionalidad. La herencia dentro de la POO es un mecanismo fundamental que se puede definir tambin como una transmisin de las caractersticas de padres a hijos. Entendiendo aqu caractersticas como mtodos y atributos de una clase. La
Pgina 8 de 19

clase hija puede aadir atributos, mtodos y redefinir los mtodos de la clase padre. Podemos ver la herencia como una sucesiva especializacin de las clases. La clase de la que se hereda se suele denominar clase padre o superclase, y la clase que hereda se denomina clase hija o subclase. El mecanismo de herencia es muy potente, puesto que nos permite agregar funcionalidades nuevas a una clase ya existente, reutilizando todo el cdigo que ya se tenga disponible de la clase padre, es decir, se heredarn sus atributos y mtodos, como ya habamos indicado con anterioridad. En las clases hijas podemos redefinir el comportamiento de la clase padre. Para verificar que la herencia entre dos clases es correcta y coherente, debemos hacernos la pregunta de "es un?" o "es un tipo de?". Por ejemplo, en el caso que comentbamos del botn, tenemos una clase BotonColor que hereda de la clase Boton. Esta herencia contesta perfectamente a la pregunta definida antes: un botn de color es un botn?, evidentemente s. Mediante el mecanismo de herencia podemos definir superclases denominadas clases abstractas que definen comportamientos genricos. De esta clase pueden heredar otras clases que ya implementan de forma ms concreta estos comportamientos. As por ejemplo podemos tener una clase bicicleta, que ser ms o menos genrica. De esta clase pueden heredar la clase bicicleta de montaa, bicicleta de carreras y tandem, que ya ofrecen una clase ms especializada que la clase padre.
Pgina 9 de 19

Los mtodos que se heredan de la clase padre no tienen porqu utilizarse sin realizar ningn cambio, se puede llevar a cabo lo que se denomina la sobreescritura de mtodos. Podemos heredar un mtodo de la clase padre, pero en la clase hija le podemos dar una implementacin diferente para que se adecue a la nueva clase. La herencia puede ser simple si la clase hija hereda de una nica clase padre o mltiple si hereda de varias clases padre, ms adelante veremos que el tipo de herencia que soporta Java es una herencia simple. MTODOS Como ya hemos dicho anteriormente los mtodos son las acciones que se pueden realizar con los objetos. Tambin se podra definir un mtodo como la implementacin de un mensaje, al fin y al cabo, un mensaje es la llamada o invocacin de un mtodo de un objeto. Existen dos mtodos especiales que se denominan constructor y destructor. El mtodo constructor se ejecuta automticamente cada vez que se crea un objeto de la clase en cuestin, sobre el objeto que acaba de crearse, inmediatamente despus de haberse asignado memoria a dicho objeto. Algunos lenguajes proporcionan un constructor por defecto, pero generalmente lo correcto es que lo defina el diseador de la clase y que en l se lleven a cabo las inicializaciones y todas aquellas operaciones que se necesiten para poder usar el objeto. El mtodo destructor se invoca automticamente inmediatamente antes de liberar la memoria del objeto en
Pgina 10 de 19

cuestin, o lo que es lo mismo, antes de que se salga del mbito de la declaracin del objeto, por lo que se ha de emplear para que la destruccin del objeto se efecte correctamente y contendr operaciones tales como liberacin de memoria asignada dinmicamente dependiente del objeto, grabacin de todos o parte de los atributos del objeto en un fichero o base de datos y operaciones similares. POLIMORFISMO El trmino polimorfismo expresa la posibilidad de que el mismo mensaje, enviado a objetos distintos, ejecute mtodos distintos. Esto significa que podemos definir dentro de dos clases distintas dos operaciones con el mismo nombre y aspecto externo, pero con distintas implementaciones para cada clase. En el momento de emplear estas operaciones, el lenguaje es capaz de ejecutar el cdigo correspondiente dependiendo de la clase del objeto sobre el que se ejecuta la operacin. Esto permite definir un interfaz comn, un aspecto externo idntico, para una serie de clases. De esta forma podemos definir un mtodo suma() para la clase Enteros y otro mtodo suma() para la clase Matrices. El mensaje ser el mismo, pero la implementacin de los mtodos ser distinta ya que no es lo mismo sumar enteros que matrices. SOBRECARGA La sobrecarga de mtodos se produce cuando una clase tiene mtodos con el mismo nombre pero que difieren o bien
Pgina 11 de 19

en el nmero o en el tipo de los parmetros que reciben dichos mtodos. Un ejemplo de sobrecarga los podemos tener en el mtodo imprimir(), mediante este mtodo vamos a imprimir en pantalla y realizar un salto de lnea. Este mtodo acepta como parmetro una variable de tipo entero o una variable de tipo cadena de caracteres, incluso si no indicamos ningn parmetro realizara un salto de lnea. MODELO DE OBJETOS El modelo de objetos es un conjunto de principios que se deben dar para que se puedan modelar objetos computacionales (objetos dentro de nuestro cdigo y programas) a partir de objetos de la realidad de manera que stos reflejen los posibles comportamientos presentes en la realidad y compongan un modelo computacional vlido. Es decir, definido e identificado un problema se trata de realizar una representacin lgica de los objetos que forman parte del problema en el mundo real, de esta forma podremos utilizar en nuestro programa estos objetos para dar la solucin a travs de nuestro cdigo. El modelo de objetos que definen un problema de la realidad se basa en los siguientes principios: abstraccin, encapsulacin, herencia y polimorfismo. Todos estos conceptos bsicos de la POO ya han sido discutidos en este tema en mayor o menor medida. Por lo tanto antes de empezar a construir un programa para una tarea especfica, es necesario construir y disear su modelo de objetos. Existen diversas tcnicas de modelizacin,
Pgina 12 de 19

pero el objetivo de este curso no es el de explicarlas, as que no entraremos en ms detalles. RELACIONES ENTRE CLASES Una clase por s sola no ofrece una funcionalidad demasiado interesante, como ya veremos a lo largo del curso, el lenguaje Java se encuentra formado por un gran nmero de clases que forman parte de una compleja jerarqua. Cada una de las clases est especializada en una funcin o tarea especfica, es decir, se da una gran modularidad, cada clase tiene su cometido. Por lo tanto para ofrecer una mayor funcionalidad y realizar tareas ms complejas es necesario que exista una relacin entre las clases. Un ejemplo podra ser las piezas del motor de un coche. Las piezas por si solas no realizan ninguna tarea de importancia, cuando realmente se saca provecho de ellas es cuando se relacionan entre s y se construye con ellas un motor. A su vez este motor puede ser incorporado dentro de un coche, que estar compuesto a su vez de ms objetos o piezas. Como vemos la correspondencia entre los objetos del mundo real y los objetos del mundo computacional es bastante obvia en algunos casos. Bsicamente una clase se puede relacionar con otra de tres formas diferentes. Las relaciones que podemos distinguir son: Relacin de composicin: una clase puede estar compuesta de otras clases. Esto se consigue implementando los atributos de la clase como objetos de otra clase. Una clase hace uso de otra a travs de sus atributos, una clase se encuentra formada por varias
Pgina 13 de 19

clases. Por ejemplo la clase Coche tiene atributos que son de la clase Puerta, Rueda, Motor, etc.

Relacin de uso: una clase se relaciona con otra a travs de los mensajes que le enva. Esto se consigue pasndose una instancia de la clase como uno de los parmetros del mtodo invocado por el mensaje. Es decir, si tenemos la clase Pantalla con el mtodo dibujar() y queremos dibujar un objeto de la clase Rectangulo, deberamos realizar lo siguiente dibujar(Rectangulo), es decir, el parmetro que se le pasa al mtodo dibujar() de la clase Pantalla es un objeto de la clase Rectangulo. Relacin de herencia: este tipo de relacin entre clases ya la conocemos y consiste en que una clase hija hereda de una clase padre o superclase pudiendo utilizar as toda la funcionalidad ofrecida por la clase padre y aadir nuevas funcionalidades. En esta forma de relacin se consigue la reutilizacin del cdigo y una progresiva especializacin a travs de una jerarqua de clases.

VENTAJAS E INCONVENIENTES DE LA POO En este apartado vamos a comentar que ventajas nos ofrece el paradigma de la POO, tambin mostraremos algunas de sus desventajas. Como ventajas o aportaciones podemos destacar las siguientes: Facilita la reutilizacin del software. A travs de la herencia se nos permite utilizar en un objeto las operaciones implementadas para otros sin esfuerzo
Pgina 14 de 19

adicional. Por otro lado la encapsulacin nos facilita el uso de objetos que no hemos definido ni implementado.

Facilita la construccin de programas portables. Es posible disear una capa de objetos que se comunique con la mquina o el sistema operativo, y sobre sta los objetos que dan funcionalidad a la aplicacin. Una migracin a otra arquitectura slo requerir cambios en dicha capa, y el encapsulamiento nos garantiza que los cambios se van a limitar a esos objetos. Java refuerza ms esta caracterstica de la portabilidad, ya que, como veremos en el prximo captulo, el lenguaje Java es independiente de la plataforma en la que se ejecuta. Facilita el mantenimiento. El encapsulamiento nos garantiza que las modificaciones realizadas en un objeto tendrn un efecto limitado. Si un elemento de datos se accede directamente y en un momento dado cambia de tipo o formato, habr que localizar todos los puntos en los que se accede a dicho elemento y modificarlos en consecuencia. Si este elemento de datos est encapsulado en un objeto y siempre es accedido mediante las operaciones disponibles, un cambio como el indicado se limitar al objeto, del que slo habr que cambiar el elemento de datos y las operaciones del objeto que lo utilizan. Lo recomendable es desconocer la implementacin interna del objeto, nosotros necesitaremos utilizar un objeto que ofrece una serie de funcionalidades, pero no nos interesa de que forma nos ofrece las mismas.
Pgina 15 de 19

Provoca que las tareas de anlisis, diseo e implementacin sean ms intuitivas, ya que se manejan objetos, concepto con el que todos estamos familiarizados, y estructuradas, ya que podemos asignar las tareas de diseo e implementacin a nivel de objetos. Se debe recordar que los objetos en nuestros diseos van a representar objetos presentes en el mundo real. No todos son beneficios, la POO ofrece tambin una serie de desventajas, aunque ms que desventajas o inconvenientes podemos decir que presenta una serie de dificultades, las cuales se comentan a continuacin: Curvas de aprendizaje largas, debido principalmente a que implica un cambio mentalidad, y no slo el aprender un nuevo lenguaje.

Dificultad en determinar las caractersticas de un objeto. Debido a que un objeto no se define aisladamente, sino que depende de las relaciones con otros objetos, el establecimiento de nuevas relaciones puede implicar un cambio en la definicin del objeto y viceversa. Por todo ello es conveniente iterar, esto es, repetir el proceso de definicin de objetos y de identificacin de relaciones, tantas veces como sean necesarias para alcanzar un modelo estable. En muchos casos resulta complicado llegar a un modelo de objetos definitivo con el que se pueda abordar el problema planteado de forma completa. UN EJEMPLO SENCILLO No hace falta decir que el tema que nos ocupa es un tema eminentemente terico, pero aun as vamos a incluir un breve

Pgina 16 de 19

y sencillo ejemplo con el que se pretende mostrar de forma sencilla como se puede construir un modelo de objetos, identificando los objetos que intervienen en el problema a resolver, definiendo los atributos de la clase, los mtodos, relaciones entre las diferentes clases, etc. En este caso vamos a abandonar los tpicos ejemplos de la clase Coche y similares y vamos a mostrar un ejemplo ms ldico. En nuestro ejemplo vamos a tener la clase VideoJuego, es decir, vamos a crear el juego de matamarcianos conocido por todos. No vamos a profundizar demasiado en todos los atributos y mtodos de las clases, sino que vamos a mostrar nicamente los ms relevantes. En el primer paso vamos a identificar las clases necesarias para abordar nuestro problema, en este caso, la creacin de un juego de matamarcianos. Primero tengamos en cuenta las especificaciones: En el juego tenemos dos tipos de enemigos: marcianos y venusianos.

El protagonista del juego es un terrcola.

El terrcola dispone de un arma para defenderse de los enemigos, un lanza cohetes. Como se puede observar no vamos a tener demasiadas complicaciones a la hora definir el modelo de objetos de nuestro programa. Se pueden distinguir seis clases: VideoJuego, Enemigo, Marciano, Venusiano, Terricola y LanzaCohetes.
Pgina 17 de 19

La clase VideoJuego sera la clase principal y contendra al resto de las clases. Por lo tanto entre la clase VideoJuego y el resto de las clases existe una relacin de composicin. Esta clase tendra como atributos posibles: Enemigos, Heroes y Armas; y como mtodos: comenzarPartida(), interrumpirPartida(), reanudarPartida() y finalizarPartida(), la finalidad de cada uno de ellos est clara. La clase Enemigo en realidad va a ser una clase abstracta, ya que no vamos a instanciar objetos de esta clase. La clase Enemigo va a ser la clase padre de la clase Marciano y Venusiano, y lo que se consigue con esta clase es agrupar todo el comportamiento que es comn a los enemigos que aparecen en el juego. Esta clase tiene los siguientes atributos: Color, NumeroOjos y NumeroPiernas. Estos atributos sern comunes a las clases Marciano y Venusiano. Existe una relacin de herencia entre la clase Enemigo y las clases Marciano y Venusiano. La clase Enemigo podra tener los siguientes mtodos: mover(), atacar() y disparar(). Estos mtodos tambin sern heredados por la clase hijas mencionadas. Las clases hijas tienen dos opciones, si la implementacin de los mtodos anteriores que realiza la clase padre es la adecuada, los heredarn y utilizarn sin ms, pero si las clases hijas quieren realizar modificaciones o ampliaciones sobre los mtodos heredados debern implementarlos y por lo tanto sobreescribirlos aportando un comportamiento diferente. Las clases Marciano y Venusiano pueden adems de sobreescribir los mtodos heredados de la clase Enemigo, aportar nuevos mtodos y nuevos atributos. La clase
Pgina 18 de 19

Marciano aade el atributo Visible, es decir, nuestro amigo tiene la capacidad de hacerse invisible, y la clase Venusiano aade el atributo NumeroCabezas. La clase Terricola representa al hroe de nuestro juego y tiene los atributos: NumeroVidas y Municion, ambos requieren poca explicacin. Esta clase implementa el mtodo disparar(), que recibe como parmetro un objeto de la clase LanzaCohetes, la relacin entre ambas clases es una relacin de uso. La clase LanzaCohetes que representa el arma que va a utilizar la clase Terricola y tienen el atributo NumeroCohetes, y posee el mtodo lanzarCohete(). Podramos entrar en ms detalles e ir afinando ms en la identificacin de objetos, podramos definir tambin la clase Cohete, que representara a los cohetes lanzados por una instancia de la clase LanzaCohetes. Pero no vamos a entrar en ms detalles y vamos a dejar de definir ms clases, quedndonos con las vistas hasta ahora.

Pgina 19 de 19