Lenguajes de Programaci on Ayudant a 2: Objetos, Objetos Everywhere Versi on 1 - Semestre 1

Camilo Zambrano Lagos <cizambra@alumnos.inf.utfsm.cl> 22 de mayo de 2012

1.

Introducci on

Esta ayudant a consistir a en realizar una introducci on breve, pero clara, al paradigma de orientaci on a objetos, permitiendo al estudiante aprender y entender todo lo necesario para comprender el mundo en el que se encuentra situado, de forma que le permita solucionar problemas reales en forma simple y efectiva. En esta ocasi on se ense nar an conceptos clave relacionados con este paradigma, estableciendo una base te orica, que luego se complementar a con la ense nanza de las aplicaciones pr acticas, entre las que se encuentran los lenguajes de programaci on orientados a objetos.

2.
2.1.

Orientaci on a Objetos
Breve Historia

Podr a decirse que la orientaci on a objetos es un enfoque relativamente nuevo, que comenz o a concretarse conceptualmente a nes de los a nos 70, sin embargo, comenz o a ser realmente utilizado y elegido como enfoque de programaci on mas o menos por la d ecada del 90, donde hubo una suerte de explosi on en cuanto a la masicaci on del uso de este enfoque en el desarrollo de software; a pesar de lo anterior, es preciso decir que fue a partir de la d ecada de los 80 donde la gente comenz o a reconocer los benecios de la orientaci on a objetos por sobre el enfoque estructurado.

2.2.

Qu e es la Orientaci on a Objetos?

La orientaci on a objetos es un m etodo que incluye disciplinas de desarrollo y modelamiento de software, facilitando la construcci on de sistemas complejos a partir de componentes. El pilar fundamental de la Orientaci on a Objetos como paradigma, corresponde a la abstracci on. La abstracci on, como concepto, corresponde a la acci on de aislar las propiedades fundamentales sobre un objeto, dejando aquellas propiedades prescindibles de lado, de modo que se genere una visi on gen erica y simple del mundo real, o de situaciones insertas en el mundo real, en forma de modelo. En la orientaci on a objetos, cada objeto resultante del proceso de abstracci on tiene su s mil a nivel de software. Estos s miles, representan su estado atrav es de uno o m as atributos o propiedades y poseen un comportamiento implementado en forma de m etodos, tales comportamientos pueden manipular el estado de cada atributo; ambos componentes son llamados miembros.

2.3.

Conceptos Fundamentales

Para entender la Orientaci on a Objetos, es necesario comprender a cabalidad ciertos conceptos clave. A continuaci on se explicar an y luego se presentar a una relaci on m as completa entre tales t erminos. 1. Objeto: Encapsulamiento de un conjunto de operaciones (m etodos) que pueden ser invocados externamente, y de un estado que recuerda el efecto de los servicios 1 . Todo objeto posee tiempo de vida, estado y comportamiento. 2. Clase: Corresponde a una clasicaci on dada por la abstracci on que representa a un conjunto de objetos del mundo real con caracter sticas y comportamientos comunes, es una especie de plantilla de lo que ser a el objeto. Es un conjunto de cosas (f sicas o abstractas) que tienen el mismo comportamiento y caracter sticas... Es la implementaci on de un tipo de objeto (considerando los objetos como instancias de las clases) 2 . 3. Instancia: Es un objeto concreto, en un estado determinado, con comportamiento y propiedades denidas en un momento determinado. A partir de lo mencionado, se puede obtener una relaci on obvia entre estos tres elementos: La clase dene las variables que poseen los objetos de esa clase y los m etodos implementables. Son una plantilla, un manual de construcci on, un plano, de objetos concretos. Luego de denir la clase, se puede continuar con la instanciaci on de un objeto en un momento determinado, con caracter sticas determinadas de acuerdo a las reglas impuestas por la clase. Ejercicio 1.a Cierre los ojos y piense en su pieza. Anote en su cuaderno una lista de todos los objetos que recuerde y describa su comportamiento y propiedades. C omo podr an relacionarse?.

2.4.
2.4.1.

Principios fundamentales
Abstracci on

Como ya se ha mencionado, la abstracci on como concepto es el pilar fundamental en la orientaci on a objetos, ya que sin la existencia de esto, los modelos simples no podr an ser posibles. Nuestra mente nos permite entender la realidad realizando modelos basados en objetos que se interrelacionan y comunican de modo que la suma de todos estos elementos, forman el todo en el que nos situamos. Es importante notar que la mente, as como es capaz de modelar usando como elementos constructores de la realidad a los objetos, tambi en es capaz de ver tales objetos como elementos denidos y concretos, no se preocupa de la composici on de estos, si no que de la suma de los componentes invisibles, el resultado nal. Si lo anterior no se entendi o, s olo piense en c omo su mente no ve al cuerpo humano como un conjunto de c elulas, o c omo no ve a una casa como un conjunto de ladrillos; la mente tiene la capacidad de concentrar las caracter sticas que realmente nos importan, y generar modelos m as simples o m as complejos en base a nuestras intenciones y percepciones de la realidad. 2.4.2. Encapsulamiento

En la realidad, un objeto no siempre muestra p ublicamente su estado; una persona puede poseer ciertos datos que no quiere revelar al resto de objetos que lo rodean, por ejemplo, lo que est a pensando en un momento determinado pueden sus amigos determinarlo con certeza?, lo m as humano y real ser a responder que no (a menos que sea el Profesor X3 ). El encapsulamiento se trata precisamente de eso, de la posibilidad de los objetos de permitir o no, a acceder a ciertas propiedades o comportamientos por parte de otros objetos que interact uen con el. Un objeto puede permitir acceso exclusivo a sus miembros, ofreciendo m etodos de acceso, controlando el acceso a los datos, de modo que se eviten problemas por un acceso indebido (sin permiso) a los datos privados. En el ejemplo mencionado, usted como individuo, puede dar a conocer su pensamiento a la gente que usted desee, a trav es de un escrito, conversaci on, dibujos, entre otras opciones de expresi on.
1 Piattini 2 Piattini

et al., 1996 et al., 1996 3 Personaje de la serie de c omics Xmen, quien tiene la capacidad de leer la mente de las personas.

2.4.3.

Modularizaci on

Este principio est a enfocado especialmente en el desarrollo de software utilizando Orientaci on a Objetos, aqu se propone al programador separar su trabajo en piezas (m odulos) consistentes y bien denidas, con el n de atacar el problema por partes, bajo la m axima Divide et Impera4 , disminuyendo la dicultad de este. 2.4.4. Herencia o Jerarqu a

Suponga que Juan tiene un conjunto de mascotas diferentes compuesto por cinco gatos y tres perros. Usted a simple vista podr a determinar ciertas caracter sticas comunes entre tales mascotas, como lo son por ejemplo, la raza, el pelaje, el color del pelaje y el tama no. Estas caracter sticas corresponden, como usted bien puede observar, a las propiedades de un animal, independiente de que tipo de animal se trate, por lo que podr a generarse un modelo com un que ocupe estas caracter sticas para determinar el estado de cada una de estas mascotas. Estamos procediendo bien? Por supuesto que si!, el modelo depende netamente de lo que el programador o dise nador estime necesario, ya que no hay l mites para las abstracciones. A partir de lo anterior, podriamos denir una clase llamada Animal, cuyas propiedades ser an las ya mencionadas. Qu e suceder a si deseasemos entrar a un nivel m as detallado de clasicaci on? Qu e podr amos hacer para lograr alcanzar el detalle usando como base una generalizaci on?. La jerarqu a o herencia, corresponde a la forma que tienen los objetos de organizarse. En la orientaci on a objetos se representa en el traspaso de ciertas caracter sticas desde una clase a otra. Las clases que toman las propiedades, son llamadas subclases o hijas y las que otorgan de cierto modo las propiedades, son llamadas superclases o padres. El acto de tomar las propiedades de una clase padre es llamado heredar. La herencia es un concepto que no solamente es utilizado en inform atica, en general el concepto de herencia es ampliamente usado en cuanto a taxonom a se reere, y un ejemplo de ello es la taxonom a de los seres vivos. Por ejemplo, la clasicaci on de los seres vivos conlleva una serie de jerarqu as, que reejan en forma f acil lo explicado en este principio, y en el que claramente se demuestra que a medida que el nivel de clasicaci on es m as bajo, el nivel de detalle es mayor (sin dejar de lado las caracter sticas comunes subyacentes). Una forma de representar esta taxonom a a nivel de objetos, es la utilizaci on de arboles de herencia (ver Fig. 1), en el que los nodos superiores corresponden a las superclases (con sus atributos y m etodos), y los nodos inferiores son las subclases(con sus atributos y m etodos). Ejercicio 1.b Genere un arbol de herencia basado en el ejemplo, cuya ra z corresponda a la clase Animal. 2.4.5. Paso de Mensajes

Los objetos tienden a recurrir a otros objetos para determinar ciertos objetivos, para eso es necesario que se comuniquen. La comunicaci on entre objeto se realiza atrav es del paso de mensajes, en el que el objeto A puede solicitar alguna acci on o realizar alg un cambio de estado sobre el objeto B , a nivel de software, esta operaci on se realiza haciendo uso de los m etodos. 2.4.6. Polimorsmo

Muchas veces un objeto se comporta diferente seg un el contexto en el que est e inserto, por ejemplo, usted habla de forma diferente seg un las personas con las que est e teniendo contacto en ese momento, usted habla distinto con sus amigos, con sus profesores y con sus pap as. A este comportamiento diverso que presentan los objetos, seg un el contexto en el que est e inserto se le denomina polimorsmo, t ermino que proviene del griego y que signica que posee varias formas diferentes. Como ya se vi o antes, el comportamiento de un objeto est a en general dado por sus m etodos, por lo cual, seg un el contexto, el polimorsmo se denomina de diversas maneras: de sobrecarga (el mismo m etodo en distintos objetos completamente independientes), param etrico (mismo nombre, distinto tipo y/o
4 Divide

y vencer as

Figura 1: Ejemplo de arbol de herencia tentativo de la clase Animal. nombre de par ametros) y de inclusi on (redenici on de m etodos heredados de una superclase, se puede llamar a un m etodo usando una interfaz com un, sin necesidad de entregar informaci on adicional sobre la clase que invoca al m etodo). El polimorsmo en general se puede implementar usando la sobrecarga de m etodos (no confundir con el polimorsmo de sobrecarga), la sobre-escritura de m etodos, y el ligado din amico (asociado a las llamadas interfaces).

2.5.

Relaciones entre objetos

Tanto en el mundo real, como a nivel de software, los objetos por lo general no funcionan individualmente, y siempre participa m as de uno en el cumplimiento de un objetivo com un. Es por eso es necesario establecer de qu e tipo de formas se pueden relacionar los objetos, existen muchos tipos de formas en la que se pueden relacionar tales objetos, pero nos concentraremos s olo en tres, que son los que m as destacan y los m as u tiles al momento de construir software, estos son: las relaciones de asociaci on, relaciones de todo/parte y las relaciones de generalizaci on/especializaci on. 2.5.1. Relaciones de Asociaci on

Son relaciones generales, en las que se forma una conexi on entre clases, que representa una comunicaci on de alg un tipo, esta asociaci on puede tener un nombre, puede ser bidireccional o unidireccional y puede presentar multiplicidad (m as de una instancia por relaci on, no necesariamente binaria). Estas relaciones son las que poseen menos riqueza sem antica. Es necesario recordar que la comunicaci on se realiza mediante el acceso a los m etodos de ambas clases. Ejemplos de asociaci on son las relaciones tiene un y pertenece a, en la que un objeto A posee a un objeto B y un objeto B es pose do por un objeto A respectivamente, por ejemplo, una persona tiene una mascota, por otro lado, la mascota pertenece a una persona. 2.5.2. Relaciones de Todo/Parte

Las relaciones de todo/parte, es una asociaci on especial, donde el todo se relaciona con sus partes. En esta relaci on, un objeto corresponde a un conglomerado de objetos diferentes, por lo tanto, a diferencia de la relaci on tiene un, esta relaci on ser a tildada como es parte de. Por ejemplo, una c elula es parte de una persona. Dentro de las relaciones de todo/parte, existen dos conceptos: agregaci on y composici on; la diferencia radica en que en la composici on la vida de los componentes termina cuando termina la vida del compuesto, mientras que en la agregaci on la vida de los componentes no necesariamente termina cuando termina la vida del compuesto, se puede decir que las relaciones de agregaci on son m as d ebiles que las de composici on. En las relaciones de composici on, los componentes son partes vitales del compuesto, es decir,

sin esos elementos, el compuesto no tiene sentido alguno, mientras que en la agregaci on, los componentes son prescindibles y el compuesto puede funcionar sin su existencia. 2.5.3. Relaciones de Generalizaci on/Especializaci on

Cuando n clases tienen elementos en com un, se puede abstraer una (n + 1)- esima clase, que est a compuesta por las caracter sticas comunes de las n clases, luego se dice que cada una de las n clases es una (n + 1)- esima clase. En estas relaciones se basa la herencia. Se habla de generalizaci on cuando se habla de una perspectiva ascendente o bottom-up, y de una especializaci on cuando se habla de una perspectiva descendente o top-down.

Referencias
[1] El Enfoque Orientado a Objetos - http://www.mitecnologico.com/Main/ElEnfoqueOrientadoAObjetos [2] Introducci on a la Programaci on Orientada a Objetos - http://zarza.usal.es/~fgarcia/doc/tuto2/I_1.htm [3] P arraga Garc a, Ivan - Curso de Java 3ra Edici on, 2003 [4] Polimorsmo y herencia es mucho m as potente que simplemente una herramienta de reutilizaci on - http://bit.ly/ J9UgJ4 [5] Introducci on a la Orientaci on a Objetos - http://slidesha.re/JPt74b [6] UML dise no de agregaci on vs composici on - http://bit.ly/gVAYuT

Cualquier duda, sugerencia o correcci on del documento, hacerla a cizambra@alumnos.inf.utfsm.cl