Sie sind auf Seite 1von 9

LAB.

DE PROGRAMACIÓN ORIENTADA A OBJETOS – 3º Año


Prof. Sergio Orgás

PROGRAMACION ORIENTADA A OBJETOS


INTRODUCCION
El desarrollo de aplicaciones orientadas a objetos se sustenta bajo conceptos precisos y fundamentales que se
deben comprender para una correcta adopción de las ventajas de este paradigma.
En esta unidad se describen todos estos conceptos con el objetivo de brindar un panorama general que
permita adquirir y familiarizarse con la jerga usada en el paradigma orientado a objetos.

PARADIGMAS
Un paradigma es un modelo o esquema fundamental que organiza nuestras opiniones con respecto a algún
tema en particular. Los paradigmas establecen límites, para resolver problemas dentro de estos, y de esta
forma mejorar o proporcionar nuevas soluciones, ya que estos filtran experiencias, se ajustan a los límites,
percepciones o creencias.
Un paradigma está constituido por los supuestos teóricos generales, las leyes y las técnicas para su aplicación
que adoptan los miembros de una determinada comunidad científica.

PARADIGMAS DE PROGRAMACIÓN
Representan un enfoque particular o filosofía para la construcción del software. Existen diversos paradigmas,
los que serán objeto de descripción de esta materia son: Imperativo, orientado a objetos, funcional y lógico.

Paradigma Imperativo: describe la programación en términos del estado del programa y sentencias que
cambian dicho estado. Se describe un conjunto de instrucciones que le indican a la computadora como realizar
una tarea. Debe su nombre a que está basada en comandos que actualizan variables contenidas en
almacenamientos. Las instrucciones se ejecutan en forma secuencial en un orden establecido. Un conjunto de
instrucciones conforman un programa. Los programas se pueden dividir en una serie de módulos o rutinas
distribuidos de acuerdo con una organización jerárquica. De esta forma el programa situado en la raíz de la
jerarquía se denomina Programa Principal y los demás se conocen con el nombre de subprogramas,
subrutinas, funciones o procedimientos.
Entre las reglas que se pueden destacar de este paradigma está en la definición del ámbito de las variables,
según el lenguaje que se utilice se pueden definir variables globales (accesibles por todos los programas de la
jerarquía) o locales (accesibles únicamente desde el programa al que pertenece).
Existen dos tipos de programación imperativa: la programación estructurada (no existe el goto, facilita la
modularización, documentación y mantenimiento de programas) y la programación no estructurada (con goto,
el cual permite saltar a los programas que se deseen).
Ejemplos de lenguajes imperativos son PASCAL, C, COBOL.

Paradigma Orientado a Objetos: describe la programación en término de entidades denominadas objetos y


las interrelaciones entre los objetos. Los objetos definen el conjunto de variables que solo son accesibles
dentro de la entidad denominados atributos. Los objetos además definen operaciones, que son las acciones
que el objeto puede realizar y que generalmente procesan la información almacenada en sus atributos. Las
operaciones de los objetos definen sus responsabilidades. Cuando un objeto necesita un servicio que puede
brindar otro objeto, lo que hace es enviarle un mensaje para que lo ejecute. De esta forma una aplicación
orientada a objetos es una secuencia de mensajes que los objetos se envían entre ellos para colaborar en
realización de la aplicación.
Ejemplos de lenguajes orientados a objetos son Smalltalk, JAVA y los lenguajes de .NET.

Paradigma Funcional: describe la programación en término del concepto de función. Una función y = f(x)
describe la relación entre los parámetros de entrada (x) y el resultado de la salida (y) al aplicar un proceso
definido sobre los parámetros (f(x)).
Un programa en este estilo consiste en la definición de una o más funciones. Entonces para ejecutar un
programa se dan parámetros a una función y el ordenador tiene que calcular el resultado. Entonces no hay un
orden establecido para la ejecución de los programas (como en el caso de la programación imperativa).

1
LAB. DE PROGRAMACIÓN ORIENTADA A OBJETOS – 3º Año
Prof. Sergio Orgás

No existe las asignaciones de variables y sólo se puede hacer uso de la recursividad (no existen los bucles de
control).
Ejemplos de lenguajes puros e híbridos de programación funcional son Haskell, Miranda, Lisp y Phyton.

Paradigma Lógico: describe la programación en términos de conjuntos de la lógica matemática. Permite


inferir relaciones entre valores más que calcular valores de salida a partir de valores de entrada. En general se
basan en la lógica de predicados.
Ejemplo de lenguaje de programación lógica es el PROLOG.

MODELADO EN EL ANÁLISIS Y DISEÑO DE APLICACIONES


El Modelado es el proceso de crear modelos.
Un modelo es una abstracción (representación) de una cierta realidad para:

Describir de una forma exacta dicha realidad en forma gráfica. Dicen que una imagen vale más que mil
palabras. Los mejores modelos son gráficos, es decir abstraemos la realidad en forma gráfica.
Facilitar la comunicación, porque los modelos usan una notación, entonces si el cliente y el APU conocen esa
notación, es muy probable que ambos interpreten lo mismo.
Permite generar documentación valiosa de las actividades que se realizan en el desarrollo de aplicaciones.
El/Los modelo/s debe/n ser completo/s y correcto/s antes de programar, porque la programación se realizará
en base a los modelos desarrollados.

Hay modelos particulares para el cliente, para el programador, para ambos, etc.
He aquí un simple ejemplo de modelado de la vida real, en el mismo se puede observar que los modelos se
aplican naturalmente en la vida diaria:

Imagine a una persona que desea construir una casa. En un principio, la casa sólo existe en la mente de los
futuros propietarios en forma de ideas o de sueños diversos. En algunas ocasiones, es posible que los futuros
habitantes de la casa ni siquiera sepan qué es lo que desean, o si lo que desean es factible. Los sueños
pueden estar llenos de imposibilidades y de contradicciones internas. Estas contradicciones no plantean
problemas en el mundo de los sueños; en la realidad, las inconsistencias y los obstáculos se deben resolver
para poder construir la casa.
El contratista de la construcción necesita un juego de planos sólido de la casa con una descripción de los
materiales que se van a utilizar, el tamaño de las bóvedas, la capacidad de las cañerías, etc.
El contratista sigue el plano y sabe cómo construir lo que se ha diseñado en él. Pero, ¿cómo se transforman las
ideas del propietario de la casa en el plano del contratista? Aquí es donde interviene el arquitecto.
El arquitecto es el intermediario entre el promotor y el contratista. Está preparado para convertir las ideas en
modelos. El arquitecto debe tener capacidad para extraer las ideas, convertirlas en un formato que permita la
discusión y el análisis, ofrecer sugerencias, describir las opciones más razonables, documentarlas y
confirmarlas con los propietarios.
Estas son las claves para proporcionar al propietario de la futura casa el plano que desea.
Al final de cuentas, las ideas factibles del propietario son reflejadas un plano, en un presupuesto y en una lista
de materiales. Estos son entregados al contratista quien lleva buen puerto la creación de la casa en el tiempo
definido.

CONCEPTOS

OBJETO
Es algo tangible (algo que se puede ver o se puede tocar) o intangible (algo a lo que se puede aludir o sobre lo
que se puede reflexionar).
Formalmente un objeto está definido por la siguiente relación:

Objeto = Identidad + Estado + Comportamiento

2
LAB. DE PROGRAMACIÓN ORIENTADA A OBJETOS – 3º Año
Prof. Sergio Orgás

Identidad

Todos los objetos son únicos. No existes dos objetos iguales. Esto es algo natural de nuestro universo, cada
cosa, cada persona, cada pensamiento, todo aquello que nosotros podamos pensar es único e irrepetible. Esta
característica también se aplica a los objetos. Si vemos hermanos gemelos, a pesar de ser exactamente
iguales físicamente hablando son únicos. Si vemos dos monedas de 1 peso sabemos que ambas son en forma,
color, tamaño y peso iguales, pero a su vez son dos entidades distintas. No pueden ocupar el espacio de la
misma. En los objetos que son representados por programas orientados a objetos, cada objeto posee un
identificador univoco. Esto hace que cada objeto sea único. Una característica de la Identidad de un objeto es
que posee un nombre. Este nombre ayuda a definir el conjunto de atributos y operaciones que puede poseer y
realizar el objeto respectivamente. Por ejemplo si pensamos en un ave que no puede volar, que vive en el polo
sur y que come pescado se puede intuir que estamos refiriéndonos al pingüino. Con solo definir el nombre
Pingüino ya estamos acotando sus atributos y sus operaciones.

Estado

Los objetos poseen atributos. Un atributo es una descripción de un objeto que se puede obtener mediante los
sentidos o al analizar las características del mismo. Por ejemplo si consideramos un objeto Persona, podemos
definir los siguientes atributos: nombre, edad, altura, color, fecha de nacimiento, dirección, etc. El estado de un
objeto representa el valor del conjunto de todos los atributos de un objeto en un momento específico de tiempo.
Supongamos que analizamos en este momento a una persona y consultamos el valor de sus atributos
obteniendo el siguiente resultado: El objeto se llama Juan Pérez, tiene 12 años, mide 1.70 metros y es de tez
morena. Vive en la calle Albarracín 234 y se fecha de nacimiento es el 11/11/96.
El estado del objeto Juan estaría definido por todos esos valores. Por eso se dice que: “en todo momento el
estado de un objeto está definido por sus atributos”.
Y realmente es así. Supongamos que pasó un año y nos topamos de nuevo con el objeto Juan Pérez y al
preguntarle sobre sus datos personales, resulta que ahora vive en Gorriti 23, tiene 13 años y pegó un estirón
de 2 cm.

Comportamiento

El comportamiento representa todas aquellas cosas que le pedirías que haga ese objeto. Es decir es el
conjunto de acciones que puede realizar.
Por lo tanto un objeto es algo a lo cual podemos definir sus características y todo aquello que puede hacer.
Esta es una de las características que hacen poderoso a los objetos. Nosotros encapsulamos toda la
funcionalidad (aquello que puede hacer y la información que puede aportar) de tal manera que con solo definir
objetos definimos responsabilidades.
Si por ejemplo definimos un objeto mesa, no se nos ocurriría pedirle que corra, ya que sabemos que él no
puede tener ese comportamiento. De la misma forma cuando hablamos de un objeto televisor intuitivamente
sabemos que podemos cambiar de canal, subir volumen, cambiar el brillo, obtener el tamaño de la pantalla,
decir si es LCD o CRT.

CLASE
Es un modelo de abstracción confeccionado a partir de objetos del mundo real. Una clase define las
propiedades y el comportamiento de un juego de objetos. Una clase constituye una categoría de objetos y
actúa como plano para la creación de ese tipo de objeto. Los objetos son instancias de una clase. Por ejemplo
existe la clase Persona, con los siguientes posibles atributos: Altura, Edad, Nombre y apellido; y sus
operaciones: correr, comer, leer. Usted y yo somos instancias de la Clase Persona. Es decir según esta clase
Persona nosotros poseemos una altura, edad, nombre y apellido, además de que podemos correr, comer y
leer.
El conjunto de los atributos y las operaciones definen la estructura de la clase. Esta estructura define solo
aquello que es importante para nuestro sistema o aplicación, es decir solo se definen los atributos y
operaciones que son de importancia para nuestra aplicación.
3
LAB. DE PROGRAMACIÓN ORIENTADA A OBJETOS – 3º Año
Prof. Sergio Orgás

Cuando necesitemos otros atributos u operaciones simplemente las agregamos a la definición de la clase.
Entonces todos los objetos se crean en base a esta estructura, por lo tanto la clase es además una plantilla
para crear objetos, un molde para la generación de objetos. Aunque ahora hablamos de conceptos, quizás esto
se vuelve más fácil de entender a la hora de programar. Cuando se programa programamos la plantilla, es
decir la estructura o molde. Cuando se ejecuta la aplicación, en la medida que se necesiten determinados
objetos se crean los mismos en base a la plantilla que hemos creado; de allí que en programación se llame al
proceso de crear un objeto INSTANTACIÓN.

EL VALOR DE LOS ATRIBUTOS DE UN OBJETO EN UN DETERMINADO MOMENTO


DEFINE SU ESTADO
Todos los datos necesarios para un sistema OO se deben ubicar en los atributos de los objetos existentes (o
utilizar para calcular otros). Algunos objetos tienen pocos datos o ninguno, mientras que otros tienen muchos
datos; dependiendo por completo de las operaciones que vaya a realizar el objeto y de los requerimientos que
se necesiten del objeto.
En un punto concreto en el tiempo, los valores contenidos en los atributos representan el estado actual del
objeto. A medida que los valores de los atributos van cambiando con el tiempo, el estado del objeto también
cambia. El estado de un objeto se recuerda mientras el objeto exista en el sistema (memoria). Los valores de
atributo normalmente se modifican ejecutando una operación de objeto como respuesta a un evento interno o
externo. El trabajo del código de objeto consiste en mantener la integridad del estado del objeto, es decir, en
asegurar que el estado del objeto sea válido para dicho objeto.
Los distintos objetos almacenan atributos diferentes. Por ejemplo, el objeto cajero automático tiene atributos
como efectivo disponible, tarjetas reconocidas, código de cajero, etc. El objeto mi pluma azul tiene atributos
como, por ejemplo, cantidad de tinta restante, diámetro de punta, longitud del cuerpo de la pluma, etc.

Normalmente, los atributos se deducen después de haber decidido las operaciones que va a realizar el objeto.
Cuando sepa lo que debe hacer el objeto, podrá decidir con más claridad qué atributos necesita almacenar el
objeto para soportar estas operaciones. Los atributos de un objeto se suelen conocer inicialmente y se pueden
utilizar para definir el tipo de operaciones que son necesarias para mantener el valor.

LAS OPERACIONES DE UN OBJETO DEFINEN SU COMPORTAMIENTO


El objetivo principal de los objetos es que realicen operaciones en el sistema en el que existen.
La tecnología de objetos descompone todo un sistema en objetos; todas las interacciones entre el sistema y el
mundo exterior y todos los cálculos internos del sistema se realizan mediante operaciones (se definen como
métodos cuando son codificados) de los objetos.
Lógicamente, los distintos objetos realizan operaciones diferentes. Por ejemplo, algunas de las operaciones del
objeto cajero automático son dispensar efectivo, imprimir recibos, leer tarjetas magnéticamente, etc. Por otra
parte, algunas de las operaciones del objeto mi pluma azul son escribir, suministrar tinta, etc.
Para cada objeto, se debe preguntar: “¿Qué es lo que hace este objeto?” Es decir, ¿qué servicios proporciona
este objeto a los demás objetos del sistema? Para ello, debe tener una idea sobre cómo se va a utilizar el
objeto en el sistema; de lo contrario, es posible que termine definiendo varias operaciones para cada objeto, lo
cual no resulta satisfactorio.

4
LAB. DE PROGRAMACIÓN ORIENTADA A OBJETOS – 3º Año
Prof. Sergio Orgás

Es importante entender cómo se va a utilizar el objeto en el sistema y especificar únicamente las operaciones
que sean relevantes para dicho uso.
También se debe preguntar cómo va a cambiar el estado del objeto, es decir, “¿Cómo se van a modificar los
valores que contiene el atributo del objeto?” Esta pregunta le permitirá definir operaciones para mantener los
detalles internos de un objeto.

LAS PROPIEDADES DE LOS OBJETOS


Los objetos son especialmente poderosos y útiles en el desarrollo de software porque bien aplicadas sus
propiedades permiten facilitar el trabajo, el mantenimiento y el reuso de los mismos. El término reuso se
estudiará más adelante porque merece especial atención.

La Abstracción

¿Cómo debe decidir qué operaciones y qué atributos son relevantes cuando se define el objeto mi pluma azul?
La respuesta es sencilla. Debe entender cuál va a ser el uso que los demás objetos van a dar a este objeto en
el contexto de este sistema concreto.
El objeto se modela como una abstracción de un ejemplo del mundo real en el contexto en el que existe.
Por ejemplo, en el contexto de un catálogo de productos, los atributos relevantes de una pluma serían, por
ejemplo, el modelo (o el nombre), el precio y el fabricante (por ejemplo, BIC).
Una de las operaciones relevantes en este catálogo sería cambiar el precio de la pluma.
Puede que necesite saber si la pluma se puede utilizar para escribir texto, si se puede rellenar con tinta o si se
puede cambiar el color de la tinta sustituyendo el cartucho. Sin embargo, estas últimas operaciones están más
relacionadas con el uso que el cliente vaya a dar a la pluma que ha comprado; por lo tanto, las operaciones
como rellenar tinta, escribir y cambiar tinta no son relevantes en el contexto de aplicación del catálogo y no se
deben modelar. Al determinar los atributos y las operaciones para un objeto, siempre se debe preguntar si
tienen relevancia en el dominio de la aplicación; debe evaluar siempre los atributos y las operaciones en el
contexto de aplicación, es decir, “¿Son necesarios para implementar correctamente el sistema y para satisfacer
los requisitos de negocio?” Por lo tanto se puede decir que la abstracción de los objetos es el modelado de los
atributos y operaciones que son únicamente relevantes o útiles para el dominio del problema.

La Herencia

Es una relación entre clases, en la que una clase declara a otra como su principal. Si se crea un objeto de la
clase secundaria, hereda todas las propiedades de la clase principal además de las propiedades definidas en la
propia clase secundaria. La clase secundaria puede proporcionar el comportamiento y los atributos adicionales
que sean relevantes, y también puede redefinir las operaciones que se especifiquen en la clase principal si se
necesita una implementación distinta.
Supongamos que podemos representar a las clases con la forma de un cuadrado dividido en 3 partes. En la
parte superior representa el nombre de la clase. La parte intermedia representa el conjunto de atributos de la
clase, mientras que la última parte se utiliza para representar el conjunto de operaciones de la clase. La
siguiente figura representa la relación de herencia usando esta representación de las clases:

5
LAB. DE PROGRAMACIÓN ORIENTADA A OBJETOS – 3º Año
Prof. Sergio Orgás

Podemos observar a la Clase Principal que se llama Persona. También recibe el nombre de SuperClase.
Esta superclase es padre de las Clases Alumno y Profesor. Ambas también se conocen con el nombre de
Clases Secundarias o SubClases. Nosotros manejaremos los conceptos SuperClases y SubClases.
La relación entre la SuperClase y sus SubClases se expresan mediante la frase “es un/a” o “es un tipo de” tal
como se observa en la figura anterior.
Se puede observar que las SubClases pueden agregar atributos y operaciones específicos.
Por ejemplo el Alumno necesita indicar el año en curso, o tal vez su libreta universitaria, y agregar una
operación rendir(). Sin embargo “hereda” los atributos y operaciones de Persona.
Por otro lado al leer esta relación generalmente se habla de una generalización desde los hijos al padre; o en
forma contraria de una especialización cuando se lee desde el padre hacia los hijos. Por esta razón la herencia
de los objetos también se denomina Generalización. Aquí hay otro ejemplo:

La Herencia clarifica el Diseño: el uso de clases para dividir el mundo en un número relativamente pequeño
de tipos es intuitivo, ya que los seres humanos pensamos así por naturaleza. Sin embargo, el modelo del
mundo no es tan sencillo. Al definir dos clases, podemos observar que las dos comparten muchas operaciones
y atributos en común. Por ejemplo, suponga que está implementando un sistema de control del tráfico aéreo y
que define una clase avión y una clase helicóptero; estas dos clases tienen en común determinadas
características y parece lógico reunir las funciones comunes en una clase principal denominada aeronave. Las
clases avión y helicóptero pueden heredar de la clase aeronave; sólo será necesario especificar en estas
clases cuáles son sus diferencias con respecto a la clase aeronave.

La Herencia mejora la Productividad: la herencia mejora la claridad del diseño y también mejora la
productividad, ya que se pueden crear clases nuevas rápidamente, basándose en las clases existentes. Si
existe alguna clase que no satisface las necesidades, no es necesario modificar la clase original, sino que se
puede definir una subclase nueva y se pueden especificar las diferencias en esta clase nueva.

La Encapsulación

En los objetos es la propiedad que posee el objeto de ocultar su estructura. Recordemos que al referirnos a
estructura indicamos sus atributos y operaciones.
6
LAB. DE PROGRAMACIÓN ORIENTADA A OBJETOS – 3º Año
Prof. Sergio Orgás

En pocas palabras:

1. Ocultamos los atributos de tal forma que no es posible que obtengan o asignen valores en forma directa. Por
ejemplo en una clase cuadrado, el valor de su lado quedará oculto, por lo tanto no podemos asignarle un valor
concreto o leer su valor en forma directa.

2. Ocultamos como se lleva a cabo una operación de un objeto. Solo sabemos su nombre, y que es posible
invocarlo. Es decir no sabemos cómo realiza la operación solo que el resultado será la acción de realizar dicha
operación.

Por ejemplo, para solucionar el problema de que no podemos leer ni asignar un valor en forma directa al lado
de un cuadrado, se crea una operación leerLado() y otra que se llame por ejemplo asignarValorAlado(valor).
Cómo realiza la lectura o cómo le asigna el valor al lado, no lo sabemos, no lo podemos ver y, en última
instancia no nos interesa.
Sólo nos importan los resultados, que se asigne el valor o que podamos leer qué valor tiene el lado Con la
encapsulación, el desarrollador puede utilizar un objeto e ignorar los detalles de nivel inferior sobre cómo se
estructura el objeto y cómo funciona internamente. De este modo, el desarrollador puede trabajar en un nivel
superior de abstracción.
Esto permite abarcar más objetos y entender mejor los sistemas complejos.

Comparemos esto con el mundo real: Si tuviéramos que entender el funcionamiento de las cosas para poder
utilizarlas, no podríamos usar muchos de los objetos reales (por ejemplo, cajeros, aviones, hornos microondas,
computadoras o grabadoras de vídeo). Para utilizar estas cosas, nos valemos de sus interfaces e ignoramos
sus implementaciones.
Una ventaja añadida es que la implementación de las operaciones puede cambiar, pero las podemos seguir
utilizando como siempre.
Piense de nuevo en un cajero. Si el banco reescribe el software o cambia el hardware del cajero, no tiene que
informar a todos los usuarios sobre cómo utilizar el nuevo sistema. La interfaz no ha cambiado y, por lo tanto, el
cajero se sigue utilizando de la misma forma. Si observa pequeños cambios en la interfaz del cajero,
probablemente quiere decir que el software se ha reescrito por completo.

INTERACCIÓN ENTRE OBJETOS USANDO MENSAJES


Cuando modelamos una realidad empezamos a describir objetos, por todos lados aparecen objetos.
Resulta además que los objetos interactúan entre ellos. Cuando un objeto necesita algo de otro simplemente
debe pedírselo.
Por ejemplo en el proceso de extraer una botella de una heladera, simplemente abrimos la heladera y sacamos
la botella.
Si queremos representar este proceso en la terminología de los objetos, diremos que yo soy un objeto de la
clase Persona, y la heladera de mi casa es un objeto de la clase Heladera.
Para poder extraer la botella de la heladera, debemos ponernos del lado de ser corteses, es decir expresar la
obtención de la botella como una petición a la heladera; entonces la heladera es un proveedor de servicios y
nosotros debemos gentilmente pedirle la botella.
Esto es fundamental para entender cómo se comunican los objetos Las operaciones que pueden hacer los
objetos son considerados servicios. Estos servicios están disponibles para otros objetos (o para el mismo
objeto). Cuando otros objetos los necesitan tienen que solicitar el servicio. Esta solicitud se realiza a través de
un mensaje. Entonces el objeto de la clase Persona le envía un mensaje solicitando la botella.
¿De qué forma va a solicitar el servicio?: Esto va a depender del protocolo de mensajes usado por los objetos.
El protocolo de mensajes define la forma en la cual los objetos se comunican entre sí mediante el uso de
mensajes. Es decir describe la sintaxis y semántica de la definición de los mensajes.
Supongamos que el protocolo define la siguiente regla:

Para obtener el servicio de una clase, debo colocar el nombre de la clase seguido de un punto, y finalmente el
nombre del servicio.

Si el objeto Heladera denominó a la acción de entregar la botella como “entregar botella”, cuando la Persona
necesite una botella el mensaje que enviará será “Heladera.entregar botella”. Entonces la Heladera sabrá
cual es la acción y la respuesta que dará gracias al nombre de la acción.
Formalmente el protocolo de mensajes es un contrato que establece un objeto para que el resto de los objetos
puedan acceder a los servicios que brinda, es decir define la forma que en un objeto indica a los demás como
deben solicitarle un servicio.
7
LAB. DE PROGRAMACIÓN ORIENTADA A OBJETOS – 3º Año
Prof. Sergio Orgás

Volviendo al ejemplo de la Heladera, ella puede definir algo así:

Nombre del Servicio u operación que brindo: “entregar botella”.


Protocolo de Mensaje definido: entregar botella (cantidad de botellas).
Entonces cuando la Persona necesite 3 botellas necesariamente deberá mandarle el siguiente Mensaje:
Heladera entregar botella(3).

Como vemos, en el mensaje intervienen el objeto al que se le solicita un servicio y el nombre de la operación
bajo la nomenclatura establecida en el protocolo de mensajes. No hay forma de que podamos solicitar de otra
forma una botella que no sea la establecida, por eso es un contrato. Este concepto es importante, y no tiene
nada que ver con la programación. Los diferentes lenguajes lo expresan de diferentes formas.
Por ejemplo en JAVA sería algo así:

Definición del Contrato

public void entregarBotellas(short cantBotellas){


// código
}

Y luego, Persona, para expresar que necesita una botella de una Heladera podría hacer algo así:

Public Class Persona{


public void obtenerBotellas(Heladera unaHeladera, short cantBotellas){
unaHeladera.entregarBotellas(cantBotellas)
}
}

Lo que está en rojo indica la solicitud de un servicio de la Heladera por medio de un mensaje.

POLIMORFISMO

El polimorfismo es la cuarta propiedad de los objetos. No se había descripto en el apartado propiedades ya que
es necesario comprender anteriormente el concepto de invocación de servicios de objetos por medio de los
mensajes.
El término polimorfismo (del griego “muchas formas”), aplicado a la tecnología de objetos, significa que se
puede definir la misma operación para clases distintas, y que cada objeto de las diferentes clases responderá
de forma diferente al mensaje.
Formalmente hablando, el polimorfismo es la habilidad que tienen diferentes tipos de objetos para responder en
forma diferente al mismo mensaje.
La implementación de una operación se denomina método; por lo tanto, polimorfismo significa que pueden
existir diversas formas de implementar métodos para una operación. En el ejemplo de la siguiente figura, hay
una operación denominada “carga de pasajeros”, pero cada clase tiene un método distinto para implementar la
operación.

¿Por qué es Importante el Polimorfismo?: la importancia del polimorfismo radica en que la operación de
carga de pasajeros se puede llamar en un objeto de cualquiera de las tres clases, y el método correcto se llama
automáticamente. Esto libera al emisor de la llamada de la tarea de tener que preguntar al objeto para
determinar su clase exacta. El polimorfismo requiere que un objeto pueda enviar un mensaje igual (o común) a
distintos objetos, permitiendo así que dichos objetos respondan a su manera.

8
LAB. DE PROGRAMACIÓN ORIENTADA A OBJETOS – 3º Año
Prof. Sergio Orgás

Otro ejemplo: si tiene la superclase ItemDeInventario y las subclases Película, VCR, Juguete, etc., puede
ampliar la tienda con facilidad con nuevos artículos subclasificando desde ItemDeInventario.
El desarrollador que crea la aplicación genera un CatalogoDeItems que es una lista de ItemsDeInventario.
Como ItemDeInventario es la Superclase de todas las demás clases (Persona, VCR, Juguete, etc.), cuando a
cada elemento de esta lista invocamos los métodos getDescripcion() y getPrecio(), podrá presentar la página
del catálogo sin necesidad de conocer con detalle todas las subclases. De hecho, si por ejemplo para obtener
el precio algunos ítems poseen particularidades propias, estas son independientes del CatalagoDeItems,
entonces el mismo enviará el mensaje getPrecio() a cada cada ítem y cada uno responderá como debe
hacerlo. Por otro lado, trabajar de esta forma permite agregar diversos ítems totalmente diferentes sin la
necesidad de modificar al CatalogoDeItems.

Características de las operaciones polimórficas

Los Operaciones Polimórficas Deben Tener el Mismo Comportamiento Lógico: Hay que pagar un
pequeño precio por las ventajas del polimorfismo. Los objetos que implementan la operación de carga de
pasajeros deben tener la misma semántica (deben llamarse igual).
Por ejemplo, si define una operación de carga de pasajeros para un crucero que signifique “subir pasajeros
borrachos”, no sería polimórfico en significado con otros métodos que significaran “subir pasajeros a bordo”.

Los Operaciones Polimórficas Deben Tener la Misma Firma: Los métodos polimórficos deben tener la
misma firma; es decir, los argumentos transferidos a la operación y el valor devuelto deben ser consistentes en
todas sus operaciones polimórficas.

Hasta aquí pareciera que el polimorfismo cobra importancia únicamente a la hora de programar, sin
embargo esto está lejos de la realidad: es cierto que cuando programemos deberemos establecer la acción
de una operación y de esa forma lograr que los objetos reacciones de forma distinta al mismo mensaje. Sin
embargo en el modelado el polimorfismo es muy importante. El no entender cómo actúa el polimorfismo causa
los problemas de mal entendimiento entre lo que dice el cliente y lo que entendemos nosotros. Si tuviéramos
presente que muchas de las cosas que dice el cliente es polimórfico, esto nos llevaría a ser más cuidadoso
para armar un vocabulario y mantener una terminología sin tener que crear palabras artificiales para sustentar
una unicidad innecesaria de términos.
También pareciera que el concepto es simple de entender y de usar: sin embargo la realidad indica que a
pesar de ser simple de entender no es aprovechado al 100 % en el desarrollo de aplicaciones. El hecho es que
usar el polimorfismo requiere ponerse a pensar cómo usarlo, y requiere ciertas habilidades, experiencia y
buenos estilos de programación.

Das könnte Ihnen auch gefallen