UTN FRBA Patrones de Diseo 2009

Repaso de Objetos Pgina 1 de 8

1 Qu es un objeto?
Parafraseando clases de paradigmas, un objeto la representacin computacional de un ente, que exhibe comportamiento. Lo exhibe para que otros objetos puedan interactuar con l, ya que si fuera un ente aislado, no tendra ninguna utilidad. Qu ms tiene de especial eso? Con esa definicin podramos simplemente seguir usando funciones y procedimientos, que forman el comportamiento de un sistema en s. Para qu objetos entonces, no? Los objetos agrupan datos y comportamiento en una sola entidad, y as nos facilitan varias caractersticas que vamos a trabajar en detalle ms adelante: delegacin y responsabilidad, abstraccin y encapsulamiento.

2 Cmo se conforma el software orientado a objetos?

Por objetos. Lisa y llanamente. Pero tener muchos objetos dando vueltas no sirve demasiado, entonces podramos ampliar a: Objetos que interactan entre s, envindose mensajes en un ambiente, para colaborar con las responsabilidades de cada uno en cumplir la funcionalidad requerida del software. Y pueden interactuar porque se conocen mediante referencias (variables), y se pasan entre s como parmetro.

aragorn le enva el mensaje poderOfensivo a anduril El ambiente es ese lugar mgico donde viven los objetos 1. Qu cosas intervienen en la comunicacin y accionar de los objetos? Mensajes y mtodos. Asumiendo que todos ya usaron objetos antes, pasemos simplemente a recordar la diferencia entre ambos: Un mensaje es la forma en que se comunican los objetos. Es la forma en que se avisan algo, o se le piden a otro objeto que hagan algo o se hacen una pregunta. Un mtodo es lo que va a hacer un objeto cuando recibe un mensaje. Podramos verlo como el cacho de cdigo que se ejecuta correspondiente al mensaje recibido. Lo que s es importante de ver ac, es que varios objetos pueden llegar a recibir el mismo mensaje y hacer distintas cosas. Es decir, un mensaje puede corresponderse con varios cachos de cdigo distintos, dependiendo del objeto que recibi el mensaje. El objeto que les mand el mensaje no necesita saber realmente quin es cada uno al que le manda el mensaje, slo le importa que lo entienda. A esta caracterstica la llamamos polimorfismo.

3 Polimorfismo
Es la caracterstica de que un objeto pueda usar2 a otros potencialmente distintos, sin saber realmente con cul est hablando. Ergo, para que podamos hablar de polimorfismo, tienen que haber como mnimo 3 objetos: el que usa, o cliente y por lo menos 2 objetos que el cliente pueda usar indistintamente. aragorn puede usar polimrficamente tanto a su espada anduril como a un arco, independientemente de cul tenga a mano en ese momento.
1
2

Esa magia la soporta una mquina virtual o motor, pero ese tema escapa a este apunte. Vamos a usar la palabra usar para referirnos al hecho de que en algn momento le va a mandar un mensaje.

UTN FRBA Patrones de Diseo 2009

Repaso de Objetos Pgina 2 de 8

Y dnde est el chiste del polimorfismo? El chiste est en ese objeto cliente, que se aprovecha de que no tiene que saber con quin est hablando, slo de qu mensajes tiene que entender ese alguien. Eso le permite permanecer mucho ms simple, y despreocuparse de qu va a hacer ese otro objeto. El cliente delega la responsabilidad en el otro objeto o colabora con l, sea quien sea, y confa en que el otro va a saber hacer su trabajo.

4 Delegacin y Responsabilidad
Volvemos al principio. El sw (as nos vamos a referir al software a partir de ahora) en objetos son objetos que interactan, para resolver un problema. Cada objeto distinto va a tener distintas responsabilidades y lo que no le toque a uno, se lo va a delegar a quin corresponda. Fcil no? Lo difcil ac es encontrar a los objetos, asignarles las responsabilidades, o hasta tener que partir un objeto en varios porque empieza a tomar muchas decisiones. Entonces podemos formalizar que: Delegar es que un objeto le tire la pelota a otro objeto, para que este ltimo se encargue de resolver el problema. Colaborar es que varios objetos hagan una partecita del trabajo.

5 Clases
Hasta ahora slo hablamos de objetos, pero no de dnde stos salen3. En la mayora de los lenguajes que se usan hoy en da la forma de crear objetos, es a partir de clases. Podemos decir que una clase es un molde de objetos, que nos dice qu atributos va a tener y que mensajes va a entender, porque en ella estn los mtodos que van a ejecutar los objetos al recibir mensajes. Las clases tambin surgen de las abstracciones que encontremos en el comportamiento de los objetos de nuestro sw, ya que podramos pensar en la clase como el concepto y en los objetos que salgan de ese molde, a los ejemplares concretos que responden a ese concepto (digamos que hay sillas de muchas formas, diseos y materiales diferentes, sin embargo reconocemos que todas son sillas por el concepto de silla que tenemos incorporado, y podemos reconocerlas gracias a nuestra capacidad de abstraccin). Cuando necesitamos tener varios objetos que se comporten de la misma manera, esos objetos van a ser creados a partir de una misma clase, es decir, van a ser de la misma clase. Y una vez creados, esos objetos no pueden cambiar de clase. Vamos a repasar un poquito de eso, suponiendo que tenemos nuestra clase Guerrero, que est formada de la siguiente manera:

Y no, no hay cigea de los objetos. Ni repollos de objetos. Ni los traen de Pars.

UTN FRBA Patrones de Diseo 2009

Repaso de Objetos Pgina 3 de 8

#Guerrero (variables de instancia: arma, posicion) >> moverseA:unLugar posicion := unLugarPosicion >> atacar: unaPersona unaPersona recibirDanio: self danio. >> danio ^self poderOfensivo + arma poderOfensivo >>poderOfensivo ^15

Cuando abrimos un workspace en el Smalltalk de su preferencia y hacemos

aragorn := Guerrero new.

Creamos un nuevo objeto guerrero, que decimos que es una instancia de la clase Guerrero y lo referenciamos con la variable aragorn. Cabe recalcar, que los mtodos siguen estando en la clase, pero nuestro objeto va a tener sus propias variables arma y posicion. Para poder trabajar con aragorn, primero debemos inicializar esas variables:
aragorn arma: anduril. aragorn posicion: posicionInicial.

Ah no estamos haciendo otra cosa que mandndole al objeto referenciado por la variable aragorn, el mensaje #arma: y #posicion:. Cuando eso pasa, el objeto no sabe realmente que hacer, busca en su clase el mtodo que corresponda al mensaje que recibi y lo ejecuta. Y qu pasa si no tienen ningn mtodo que corresponda? En este caso el objeto no entiende ese mensaje. Algo que podemos ver en el cdigo de arriba es la palabrita self. Self no es otra cosa que una pseudo-variable que referencia al objeto que recibi el mensaje actual, o sea, el mismo objeto en el que estamos parados.

Mtodos y variables de clase

Las clases, adems de tener el cdigo de los mtodos que ejecutarn sus instancias y el molde de variables que cada instancia deber tener, pueden tener mtodos y variables propias, que entiendan slo ellas y no sus instancias. Si lo pensamos en Smalltalk es muy fcil: las clases tambin son objetos, entonces tambin pueden tener variables y entender mensajes tal cual como venamos hablando hasta ahora. En otros lenguajes a veces las clases no son objetos de verdad, pero los mtodos y variables de clase tendrn el mismo sentido, por lo que no vale la pena profundizar en eso. Cundo puedo querer variables de clase? Cuando quiero que una partecita del estado4 de las instancias de esa clase sea siempre igual entre todas. Por ejemplo: puedo decir que todos los guerreros tienen el mismo equipo de defensa,
4

El estado de un objeto es el valor que tienen todas sus variables en un determinado momento.

UTN FRBA Patrones de Diseo 2009

Repaso de Objetos Pgina 4 de 8

entonces podra tener una variable de clase llamada EquipoDeDefensa. Cuando una persona recibe el dao de un ataque, el equipo de defensa le cubre un porcentaje de dao.
#Guerrero (mtodos de instancia) >> recibirDanio: unDanio danioRecibido:= unDanio (self equipoDeDefensa proteccionSobre: unDanio)

Cmo hace una instancia de la clase Guerrero para conocer su equipo de defensa? Se lo pregunta a su clase, que es otro objeto, por lo tanto le enva un mensaje:
#Guerrero (mtodos de instancia) >> equipoDeDefensa ^self class equipoDeDefensa

La clase Guerrero entonces entiende el mensaje equipoDeDefensa, que devolver el valor de su variable (no es ms que un getter)
#Guerrero (mtodos de clase) >> equipoDeDefensa ^EquipoDeDefensa >>equipoDeDefensa: unEquipo ^EquipoDeDefensa:= unEquipo

De esta manera, cuando ejecuto en un workspace: Guerrero equipoDeDefensa: Escudo new. Logro que todas las instancias de Guerrero respondan una instancia de Escudo cuando reciben el mensaje equipoDeDefensa. Cundo puedo querer tener mtodos de clase? Adems, claramente, de tener setters y getters de variables de clase, otros mtodos pueden ser tiles. Desde ya, todos conocemos un mtodo de clase ampliamente utilizado: new. Para instanciar un objeto de una clase le hablamos a la clase pidindole un nuevo objeto segn su molde. Podramos tener nuestros propios constructores tambin, por ejemplo:
#Guerrero (mtodos de clase) >> nuevoGuerreroEn: unaPosicion conArma: unArma |guerreroNuevo| guerreroNuevo:= self new. guerreroNuevo posicion: unaPosicion. guerreroNuevo arma: unArma ^guerreroNuevo

UTN FRBA Patrones de Diseo 2009 Cuando en un workspace ejecuto:

Repaso de Objetos Pgina 5 de 8

aragorn:=Guerrero nuevoGerreroEn: Posicion rohan conArma: Espada

new.

aragorn apuntar a un guerrero ya inicializado en la posicin de Rohan y con una espada como arma. Ntese que el mensaje rohan se est enviando a la clase Posicion, por lo tanto podemos interpretar que rohan tambin es un constructor de Posicion, que me devuelve una instancia de Posicion ya inicializada en las coordenadas del pas Rohan.

6 Herencia
Qu sucede cuando tenemos dos objetos que tienen mucho en comn, aparentemente son cosas similares, pero no son completamente iguales? Por ejemplo, cuando tenemos Espadachines y Arqueros, que atacan distinto, pero se mueven y defienden de la misma manera:

Sabemos que ambos se mueven y defienden de la misma manera, porque ambos son guerreros y toooodos los guerreros se mueven y defienden de esa nica forma. Cul es el problema ac? Primero, que cuando cambie la forma de moverse o de defenderse de los guerreros, debera cambiar tanto para espadachines y arqueros (y ni hablar si tenemos ms guerreros). Segundo, que hay un concepto de negocio que nombramos, pero no est explcito en nuestro cdigo/diseo: el guerrero. Dijimos que tanto espadachines y arqueros son guerreros, y el cmo moverse y defenderse depende del guerrero, no de cada tipo de guerrero en particular. Para explicitar eso en nuestro cdigo podemos crear una nueva clase Guerrero, que ah figuren los mtodos #defenderse: y #moverseA: e introducimos la herencia:

En el anterior diagrama, podemos ''leer'': Un espadachn es un guerrero Un arquero es un guerrero Decimos que Espadachn y Arquero son subclases de Guerrero, y Guerrero es superclase de Arquero y Espadachn. Se puede ver que ahora la definicin de los mtodos #defender: y

UTN FRBA Patrones de Diseo 2009

Repaso de Objetos Pgina 6 de 8

#moverseA: estn slo en la clase Guerrero, y en Espadachn y Arquero slo estn definidos los mtodos #atacar:. Sin embargo, a los objetos de la clase espadachn todava podemos enviarles el mensaje #moverseA:, porque el espadachn es un guerrero, y los guerreros saben moverse!! Adems, Guerrero es una clase de la que no tiene sentido tener instancias, ya que las instancias que nos interesan van a ser las de Espadachn y Arquero, y por ende podemos decir que Guerrero es una clase abstracta. Ojo. No siempre que decidamos utilizar herencia la superclase resultar una clase abstracta. En otras palabras, bien podra existir un Ballestero, que es otro tipo de Arquero, que sepa hacer otras cosas adems de las que hace un arquero.

En ste caso, en el sistema habra instancias tanto de Arquero como de Ballestero, porque nos interesara tener por un lado objetos que se comporten como simples arqueros y por otro lado, objetos que se comporten como ballesteros. Algo importante a tener en cuenta es el tipo de herencia. Existen la herencia simple y la herencia mltiple. Con la herencia simple, una clase solo puede tener una nica superclase, mientras que la herencia mltiple permite tener varias superclases. Este apunte contempla solo la utilizacin de herencia simple.

Method Lookup
Como llega un objeto a entender los mensajes definidos en la superclase de su clase? Anteriormente dijimos que cuando un objeto recibe un mensaje, busca en su clase el mtodo asociado y lo ejecuta, si no lo encuentra, no lo entiende. Ahora que tenemos herencia, podemos modificar un poco ese mecanismo: 1. El objeto legolas (es un arquero) recibe el mensaje moverseA: 2. Busca en su clase (Arquero) un mtodo para ese mensaje y no lo encuentra. 3. Busca en la superclase de esa clase (Guerrero), encuentra el mtodo y lo ejecuta. Generalizando: 1. Cuando un objeto recibe un mensaje, busca el mtodo asociado a su clase y si lo encuentra lo ejecuta. 2. Si no lo encuentra, busca en la superclase de la clase en la que est actualmente parado y si lo encuentra, lo ejecuta. 3. Si no lo encuentra, vuelve al punto 2. Eventualmente, cuando se llega a la clase Object (la raz del rbol de clases), si ah no encuentra el mtodo, comunica que no entiende el mensaje. Este mecanismo mediante el cual un objeto encuentra y ejecuta el mtodo que corresponde ante un mensaje se llama method lookup.

Redefinicin
Siguiendo con el ejemplo de los guerreros, supongamos un nuevo requerimiento: agregar caballeros, un nuevo tipo de guerrero que se defiende igual que todos los guerreros, ataca a su

UTN FRBA Patrones de Diseo 2009

Repaso de Objetos Pgina 7 de 8

manera y se mueve de manera distinta a los dems guerreros (obvio, porque tiene caballo). En ese caso, el caballero debera aprovechar la definicin del mtodo #defender: en la clase Guerrero, y redefinir el mtodo #moverseA:, quedando la solucin como sigue:

En esta solucin, el caballero posee el mtodo #moverseA:, sin cambiar nada en el Guerrero. Por ende, cuando un caballero reciba ese mensaje, encuentra el mtodo en la clase Caballero y lo ejecuta, sin la necesidad de buscar en las superclases. Ahora, agreguemos lo siguiente: Un caballero cuando se mueve a un lugar, lo hace igual que un guerrero, pero adems se cansa su caballo.
#Guerrero >>moverseA: unLugar self posicion: unLugar posicion.

El mtodo en Caballero, debera ser algo como:

#Caballero >>moverseA: unLugar self moverseA: unLugar. Hago lo mismo que un Guerrero caballo cansarse.

Pero definindolo de esa manera, cuando un caballero reciba el mensaje #moverseA:, ejecutar el mtodo en la clase caballero, y volver a mandar el mensaje #moverseA: a self, que es l mismo y volver a ejecutar el mismo mtodo, derivando en una recursividad infinita. O sea, nunca va a mirar el mtodo en la clase Guerrero. Para obligar a que funcione de la manera que nosotros queremos, buscando en la clase Guerrero el #moverseA: original y luego cansar a su caballo, debera utilizarse la pseudo-variable super en lugar de self, de la siguiente manera:
#Caballero >>moverseA: unLugar super moverseA: unLugar. Hago lo mismo que un Guerrero caballo cansarse.

super es una variable que apunta al mismo objeto que self, o sea, el objeto que recibe el mensaje, pero comienza el method lookup desde la superclase.

UTN FRBA Patrones de Diseo 2009

Repaso de Objetos Pgina 8 de 8

7 Encapsulamiento
La forma ms inteligente de aprovechar el paradigma de objetos es pensando que el encapsulamiento se trata de que quien construye un objeto lo haga de forma que quien lo use no necesite saber nada (o lo menos posible) de su representacin interna. Encapsular no es esconder En esta lnea de pensamiento, encapsular el estado interno es un servicio al usuario y no una restriccin. No es que no se pueda mostrar el estado interno de un objeto, slo que al usuario "no le interesa" conocerlo. Slo le debe interesar que el objeto ( el conjunto de objetos) tenga el comportamiento requerido: que resuelva el problema para el que fue diseado. El concepto de encapsulamiento se relaciona mucho con el de delegacin y responsabilidad, porque delegar correctamente es justamente darse cuenta de qu cosas necesito saber y qu cosas no quiero saber del objeto al que delego. Saber qu cosas dar a conocer de ciertos objetos y qu cosas encapsular, tienen que ver con la abstraccin que esos objetos representan.

8 Cmo se disea, entonces, un sistema en objetos?

Disear un sistema (en ste caso, tambin en objetos) es encontrar qu objetos va a haber en mi ambiente, repartir las responsabilidades entre estos objetos y definir cmo van a interactuar entre ellos. En esta actividad me va a ayudar tener en cuenta los conceptos y tcnicas asociados a la Orientacin a Objetos (OO) ms arriba mencionados. Todas esas tcnicas, bien aplicadas, buscan lograr un diseo con cualidades como: Que haga que tiene que hacer. Que sea simple Que tenga buenas abstracciones Que sea intuitivo Que se adecue al contexto en donde es diseado y utilizado Que sea cmodo de usar Que est documentado. Que sea claro, robusto, flexible.

En fin, cosas que aumentan la felicidad del usuario y del programador.