Mdulo 1

Caractersticas del
Paradigma Orientado a
Objetos

Programacin Orientada a Objetos

De las Heras, Sebastin

En la presente lectura vamos a describir en detalle cuatro caractersticas

fundamentales del Paradigma Orientado a Objetos:

Abstraccin
Encapsulamiento
Herencia
Polimorfismo

Es importante destacar que para que un modelo sea considerado Orientado

a Objetos, debe soportar estas cuatro caractersticas.
Cuando pensamos en la resolucin de un problema, simplemente lo
hacemos teniendo en cuenta aquellos elementos y caractersticas del
contexto que son importantes o necesarias, y descartamos todo aquello que
sea irrelevante. La Abstraccin es una caracterstica del Paradigma
Orientado a Objetos que permite identificar las partes ms importantes de
un objeto sin tener en cuenta aquellas otras que no lo son. Esta
caracterstica nos permite centrar nuestra atencin en las partes esenciales
de un problema y dejar de lado los detalles que no agregan valor en la
resolucin del problema.
Una clase define los atributos y mtodos que tendrn las instancias de la
misma. Es deseable que cada objeto oculte la informacin referente a la
estructura interna del mismo y la implementacin de sus mtodos. La
agrupacin de los atributos y mtodos en una unidad de forma tal que los
atributos son manipulados solamente por medio de los mtodos se
denomina Encapsulamiento. Se logra de esta forma, proteger la
estructura interna de un objeto contra posibles manipulaciones externas
indeseadas.
Si pensamos en los objetos que nos rodean, podremos ver que muchos de
ellos comparten caractersticas comunes. El Paradigma Orientado a Objetos
permite que un objeto herede atributos y mtodos de otros objetos. A esta
caracterstica la denominaremos Herencia. Es un mecanismo mediante el
cual podemos definir nuevas clases a partir de clases existentes. A su vez, la
funcionalidad de las clases existentes es compartida (o heredada) en las
nuevas clases. A travs de este mecanismo se requiere un menor esfuerzo
para definir nuevas clases.
Por ltimo, el Polimorfismo es una caracterstica que indica la habilidad
de los objetos de comportarse de distintas maneras ante un mismo
mensaje.
Estas caractersticas tambin ayudan al programador a simplificar la
resolucin de un programa.
Identificar estas cuatro caractersticas es un requisito fundamental para
lograr entender el Paradigma Orientado a Objetos y las analizaremos en
detalle a continuacin.

Programacin Orientada a Objetos De las Heras, Sebastin | 2

1.4.1- Abstraccin
Uno de los mayores desafos del desarrollo de software es idear la
representacin ms apropiada para la solucin a un problema. En el
momento de pensar en soluciones, algunas de ellas pueden ser muy
generales y otras muy detalladas. De aqu surge la pregunta:

Cunta funcionalidad y qu nivel de detalle debe contemplar la

solucin a un problema?

La solucin a un problema debe limitarse a cumplir con los

requerimientos y ser lo suficientemente flexible como para adaptarse a
posibles cambios.
Pensemos en la forma en la que se utiliza un automvil:
Para conducir un automvil no es necesario conocer en detalle
el funcionamiento interno del motor. Lo que interesa saber es
cmo se debe interactuar con el auto para poder
conducirlo. Esta interaccin se produce por medio de aquellos
elementos que provee el vehculo para lograr la
comunicacin: acelerador, freno, embrague, volante,
tablero, entre otros. Todos estos elementos van a conformar la
interfaz del vehculo hacia el conductor.
El motor de los vehculos ha sufrido cambios y modificaciones a
lo largo del tiempo, pero la interfaz bsica del vehculo no ha
cambiado, es decir, a pesar de las modificaciones tecnolgicas
que ha tenido un motor a lo largo de su historia, para conducir
un automvil ejecutaramos los mismos pasos que haramos
hace varios aos atrs: si quisiramos frenar apretaramos el
freno, si quisiramos acelerar apretaramos el acelerador, si
quisiramos girar usaramos el volante, etc.
En este ejemplo, el conductor hace una abstraccin de los detalles
internos del motor y simplemente se interesa en aquellos elementos con
los que se debe comunicar para poder lograr su objetivo. El inters del
conductor es poder conducir el auto, y para ello los detalles internos del
funcionamiento del motor son aislados del contexto. Es decir, desde el
punto de vista del conductor, los elementos esenciales del contexto van a
ser aquellos con los cuales se debe comunicar para lograr su objetivo. En
este caso, los elementos principales son el acelerador, freno, embrague,
volante y tablero, por decir algunos ejemplos.

Programacin Orientada a Objetos De las Heras, Sebastin | 3

Mediante la abstraccin, se intenta distinguir las caractersticas

esenciales de un objeto y resaltar la simplicidad sobre el mismo, ya que
se minimiza el resto de los detalles y caractersticas que definen a un
objeto.
Un auto est repleto de detalles y caractersticas que lo definen, pero para
nuestro inters solamente distinguimos aquellos elementos que
necesitamos para cumplir con nuestro objetivo (conducir).

A grandes rasgos, la abstraccin, permite que dispongamos de las

caractersticas de un objeto que necesitemos. Si necesitamos el objeto
Persona, podramos poner nombre, edad, direccin, estado civil, etc.
si lo necesitamos en un sistema administrativo, pero, si lo requerimos
para el rea de Biologa, dentro de sus atributos quiz tengamos,
ADN, RND, Gen x1, Gen x2, etc. y los atributos antes mencionados no
sean requeridos. En general, podemos decir que Persona cuenta con
todos los atributos mencionados aqu, pero, por el proceso de
abstraccin excluimos todos aquellos, que no tienen cabida en
nuestro sistema (Wikipedia, 2011).

Pensemos en otro ejemplo en donde veamos el concepto de abstraccin:

Supongamos que estamos observando un mapa digital y
deseamos buscar una direccin en particular. Si deseramos
conocer la ubicacin exacta de una direccin a travs del
nombre de calle y nmero entonces agrandaramos el mapa
hasta obtener un nivel de abstraccin en el que podamos
observar los nombres de las calles y la numeracin. En cambio,
si en lugar de buscar una direccin en particular deseramos
buscar la ciudad ms cercana a una localidad, entonces
reduciramos el mapa a un nivel de abstraccin en el que
solamente figuren las ciudades y no sus calles internas.

Mediante esta analoga se puede deducir que el nivel de detalle deseado

es aquel que se corresponde con nuestras necesidades.
Una radio tiene un sintonizador, una antena, un control de
volumen, etc. Para usarla no es necesario conocer en detalle su
funcionamiento interno, no es necesario conocer que la antena
captura seales de frecuencias, las convierte en seales
elctricas y por ltimo estas seales son convertidas en seales
sonoras. Simplemente lo que hacemos es encender la radio,
sintonizar alguna frecuencia y escuchar. Los detalles internos
son irrelevantes para nuestro objetivo.

Programacin Orientada a Objetos De las Heras, Sebastin | 4

La abstraccin nos permite definir a un objeto en su forma ms general sin

tener en cuenta sus detalles internos.
Un objeto de tipo Persona puede tener los siguientes atributos:
-

Nombre

Apellido

Edad

Fecha de nacimiento

Peso

Altura

Color de ojos

En cambio, si estamos desarrollando una aplicacin para administrar los

datos de los alumnos de la universidad, algunos de estos atributos son
irrelevantes para la aplicacin. Desde el punto de vista de la aplicacin, un
objeto de tipo Persona estara compuesto por los siguientes atributos:
-

Nombre

Apellido

Legajo

Fecha de ingreso

Carrera

Como podemos ver, el nivel de abstraccin puede variar de acuerdo al

contexto. A travs del anlisis del contexto, se determinan los atributos
que se deben tener en cuenta y se dejan de lado aquellos que son
irrelevantes.
La abstraccin asociada con la representacin de un libro desde el punto de
vista de un bibliotecario es diferente a la abstraccin representada por un
lector. Un bibliotecario considerara los siguientes atributos de un libro:
-

Ttulo

Autor

Editorial

Costo

ISBN

mientras que un lector considerara los siguientes atributos de un libro:

-

Ttulo

Autor

Contenido

Programacin Orientada a Objetos De las Heras, Sebastin | 5

Ejercicios

ndice

Si se desarrolla una aplicacin para un bibliotecario, entonces se debe tener

en cuenta la abstraccin capturada por ste y se desestima la abstraccin
asociada al lector, es decir, la abstraccin puede variar de acuerdo al
contexto y a los distintos enfoques que se le asocien de acuerdo a las
perspectivas de los usuarios. Conocer el ISBN (International Standard
Book Number - Nmero Estndar Internacional de Libro) es irrelevante
para el lector, pero resulta importante para el bibliotecario en la
clasificacin de los libros.

En el Paradigma Orientado a Objetos, la complejidad es

controlada por medio de la abstraccin. Es un proceso que
consiste en identificar las partes ms importantes de un
objeto y eliminar aquellas otras que son irrelevantes. Un
modelo de abstraccin debe ser simple y destacar aquellas
caractersticas que son importantes desde la perspectiva del
usuario.
Una clase puede ser vista como una estructura que encapsula y abstrae
funcionalidad. La clase define la estructura que va representar la
abstraccin que deseamos modelar y esta definicin es relativa a la
perspectiva del usuario. La estructura de la clase describe el
comportamiento esencial que van a contener sus instancias. En el momento
de definir una clase, debemos tener en cuenta los mtodos que la misma va
contener, debido a que dichos mtodos representan el comportamiento
esencial que van a tener los objetos de este tipo de clase.
La abstraccin es un proceso natural que las personas aplicamos
constantemente. Cuando pensamos en un objeto, no pensamos en todas las
caractersticas que lo componen, sino que simplemente se nos vienen a la
cabeza aquellas caractersticas principales que representan al objeto. Si
pensamos en un auto, no tenemos en cuenta todas las caractersticas que
hacen a la definicin de un auto, sino que pensamos en aquellas
caractersticas ms importantes que de acuerdo a nuestra perspectiva
representan a un auto.

Nos encontramos constantemente formando conceptos de las cosas

que nos rodean utilizando el proceso de abstraccin en el cual
desestimamos los detalles irrelevantes y destacamos aquellos otros que
son esenciales.
Cuando planteamos la solucin a un problema, es importante determinar
cules van a ser los datos que son necesarios manipular, para que a partir
de ellos podamos definir las entidades y propiedades esenciales que van a
formar parte de la solucin. Es en este momento en donde el proceso de
abstraccin toma lugar: en base a un contexto estamos identificando las

Programacin Orientada a Objetos De las Heras, Sebastin | 6

partes ms importantes y dejando de lado aquellas otras que son

irrelevantes a la solucin del problema.
Para lograr un buen nivel de abstraccin es un requisito importante tener
un buen entendimiento del problema ya que de lo contrario podramos:
Incluir en nuestra solucin algn componente innecesario o
irrelevante.
No incluir algn componente importante y necesario para la
solucin del problema.

Programacin Orientada a Objetos De las Heras, Sebastin | 7

1.4.2- Encapsulamiento
Concepto
En el mdulo anterior hemos mencionado que un objeto est compuesto
por atributos y mtodos, siendo estas ltimas funciones que operan
sobre los atributos del objeto.
La combinacin o agrupamiento de atributos y mtodos en
una unidad de forma tal que la manipulacin de los datos se
produce solamente por medio de los mtodos, se denomina
Encapsulamiento.

La encapsulacin provee un mecanismo o una capa de seguridad

alrededor de los datos o atributos que se manipulan, protegindolos de
accesos externos indeseados.

Mtodo
B

Mtodo
A

Atributos

Mtodo
C

Mtodo
D

OBJETO
En la figura se puede observar que en el ncleo del objeto se encuentran los
atributos (datos) que manipula el objeto. A su vez, este ncleo se encuentra
rodeado y protegido por un conjunto de mtodos del objeto. Mediante el
encapsulamiento se protegen los atributos de un objeto por medio de sus
mtodos.

Programacin Orientada a Objetos De las Heras, Sebastin | 8

Cmo funciona la proteccin de atributos de un objeto por medio del

encapsulamiento?

La comunicacin entre objetos se da por medio de mensajes. Lo nico que

un objeto conoce de otro objeto es el conjunto de mtodos que puede
invocar, tambin conocido como protocolo o interfaz del objeto.
Recordemos que la informacin que un objeto manipula se encuentra en
sus atributos. Un objeto nada conoce sobre los atributos internos de otro
objeto, es decir, los datos y la lgica implementada de un objeto
permanecen ocultos hacia los dems objetos.
Se logra as, separar los detalles de la implementacin de un objeto de
su comportamiento, evitando de esta forma el acceso a los datos que
manipula el objeto.
Por medio del Encapsulamiento, los objetos cuentan con una capa de
seguridad sobre los datos que manipulan, debido a que los dems objetos
que quieran tener acceso sobre estos datos, solamente podrn hacerlo por
medio de los mtodos.
A continuacin vamos a describir un ejemplo concreto que nos ayude a
entender estos conceptos.
Supongamos que tenemos una aplicacin que maneja informacin bancaria
y para ello en su modelo de clases se debe definir una clase que represente a
una cuenta bancaria. Esta clase debe representar en su estructura un
identificador de la cuenta y el saldo de la misma. Las acciones que una
persona puede realizar sobre una cuenta bancaria son extracciones y
depsitos de dinero.

Cuenta bancaria
Atributos
Nmero de cuenta
Saldo
Mtodos
Extraer dinero
Depositar dinero

Programacin Orientada a Objetos De las Heras, Sebastin | 9

En nuestro modelo de clases tambin debemos representar a los clientes

que pueden acceder a las cuentas bancarias. Estos clientes tienen entre sus
atributos su nmero de cuenta asociada.

Cliente
Atributos
Nombre
Apellido
DNI
Nmero de cuenta
El estado de un objeto est definido por los valores de sus atributos en un
momento dado. Vamos a suponer que tenemos una instancia de la clase
Cliente y otra instancia de la clase Cuenta bancaria con los siguientes
estados:
Cliente
Nombre: Franco
Apellido: Sosa
DNI: 30.123.456
Nmero de cuenta: 111-222333

Cuenta bancaria
Nmero de cuenta: 111-222333
Saldo: 5000

Qu pasara si los atributos de la clase Cuenta bancaria fueren accesibles

por cualquier objeto externo?
Cualquier otro cliente distinto a Franco Sosa podra acceder al atributo
saldo y realizar modificaciones sin que haya alguna validacin.

Programacin Orientada a Objetos De las Heras, Sebastin | 10

Saldo

Objeto desconocido
modifica el atributo saldo
del objeto cuenta
bancaria
N
cuenta

Objeto desconocido
Objeto
Cuenta bancaria 111-222333

Debera existir un mecanismo que prohba la visibilidad de los atributos

internos a un objeto y solamente modificar estos atributos por medio de los
mtodos que dispone la clase. Qu ventaja obtenemos con esto? La
implementacin del mtodo extraer dinero podra incluir una validacin
del cliente que est realizando la operacin, y en caso de que se trate de un
cliente incorrecto al de la cuenta, se debe prohibir la extraccin de dinero.

El mtodo
extraer dinero
manipula el
atributo saldo

Objeto desconocido
llama al mtodo
extraer dinero

Objeto
desconocido

Extraer
dinero
El mtodo
extraer dinero
ejecuta las
validaciones
correspondientes

Saldo

Atributos

Depositar
dinero

N
cuenta

Objeto
Cuenta bancaria 111-222333

Es posible prohibir el acceso a los atributos de un objeto? S es posible y

esto se puede lograr marcando los atributos en la definicin de la clase
como privados. Por ahora solamente mencionaremos el concepto y en el
mdulo 3 veremos la sintaxis utilizada por Java para marcar los atributos
de una clase como privados. Al hacer esto, estamos evitando que otros
objetos tengan visibilidad sobre la implementacin interna de un objeto.
Los atributos de un objeto contienen la informacin que manipula dicho
objeto, siendo esta la causa fundamental por la cual los atributos de un
objeto se deben marcar como privados.

Programacin Orientada a Objetos De las Heras, Sebastin | 11

Si otras entidades pueden modificar los atributos de un objeto se dice que

dichos atributos son pblicos. Existen otros dos niveles de control de
acceso pero por ahora solamente mencionaremos los niveles pblico y
privado.
Al igual que los atributos, los mtodos tambin pueden ser pblicos o
privados, es decir, puede haber algunas operaciones que no queramos que
sean visibles por otros objetos, razn por la cual se las pueden marcar como
privadas.
Un buen diseo de una clase permite manipular los atributos de un
objeto solamente por medio de sus mtodos y no de forma directa.
Si un objeto tiene que modificar los datos de otro objeto, solamente lo
podr hacer llamando a alguno de sus mtodos. La Encapsulacin hace
referencia a esta organizacin de un objeto en atributos y mtodos de forma
tal que los atributos son invisibles a los dems objetos y solamente se
pueden acceder por medio de sus mtodos.
Siguiendo con el escenario del ejemplo anterior, vamos a mencionar otro
caso en el que podamos analizar la aplicacin del encapsulamiento.
En este prximo escenario el objetivo es realizar un depsito en la cuenta
bancaria. Para ello, en primer lugar aumentaremos el saldo de la cuenta
accediendo al atributo saldo en forma directa.
El objeto cliente Juan Sosa intenta aumentar el saldo de su cuenta pero
por un error en el sistema, el valor ingresado es un nmero negativo:
Cliente Juan Sosa
aumenta el atributo
saldo con un valor
negativo
Saldo

Objeto
Cliente Juan Sosa

El nuevo
valor del
atributo
saldo ser
distinto al
esperado

N
cuenta

Objeto
Cuenta bancaria 111-222333

Como podemos ver, al permitir que el atributo saldo pueda ser

modificado en forma directa, existe un riesgo de que el mismo tome valores
indeseados debido a posibles errores del usuario o del sistema.

Programacin Orientada a Objetos De las Heras, Sebastin | 12

Cmo podramos evitar el riesgo de posibles modificaciones indeseadas en

los atributos de un objeto? El atributo saldo debera ser marcado como un
atributo privado para que el mismo no pueda ser modificado en forma
directa, y solamente pueda ser modificado por medio de algunos de los
mtodos del objeto. Como resultado, el cliente Juan Sosa puede aumentar
el saldo de su cuenta solamente por medio del mtodo depositar dinero.
Pero la implementacin de este mtodo incluye adems una validacin de
los valores ingresados, para que en el caso de que se ingrese un valor
incorrecto no se modifique el atributo saldo.

Objeto
Cliente Juan Sosa

Cliente Juan Sosa

llama al mtodo
depositar dinero
con un valor
negativo

Objeto
Cuenta bancaria 111-222333

Saldo

Extraer
dinero

Atributos
N
cuenta

Depositar
dinero
El mtodo
depositar dinero
valida el valor
ingresado por el
usuario.

En este caso, al ser el

valor ingresado un
nmero negativo, el
mtodo evita la
modificacin del atributo
saldo

El Paradigma Orientado a Objetos percibe a un objeto como una caja negra

que contiene datos y solamente pueden ser modificados por medio de las
operaciones que provee el objeto. Un objeto no necesita revelar sus
atributos, solamente debe mostrar las operaciones o mtodos con los que
otros objetos pueden interactuar con l. Los objetos emisores de mensajes
no necesitan conocer los detalles de la implementacin del objeto receptor
del mensaje.

El propsito de la encapsulacin es:

Mantener
los
datos
(atributos)
y
el
comportamiento (mtodos) en una unidad (objeto).
Separar la implementacin (detalles internos) de un
objeto de su interfaz o protocolo (mtodos).

Programacin Orientada a Objetos De las Heras, Sebastin | 13

La interfaz de un objeto est conformada por el conjunto de mtodos que

pueden ser ejecutados y debe ser la nica parte visible de un objeto. Por
ejemplo, la interfaz de un objeto de tipo Cuenta Bancaria est
determinada por los mtodos:
-

Extraer dinero

Depositar dinero

La implementacin de un objeto hace referencia por un lado a los

atributos de un objeto y por otro lado a la lgica interna aplicada en cada
mtodo. Por ejemplo, la implementacin de un objeto de tipo Cuenta
bancaria hace referencia a:
Los atributos:
o

Nmero de cuenta

Saldo

Los detalles o la lgica interna aplicada en cada mtodo.

Programacin Orientada a Objetos De las Heras, Sebastin | 14

Dependencia entre objetos

La encapsulacin permite reducir los niveles de dependencias entre los
objetos:
La interfaz de un objeto es vista como un contrato entre el objeto
emisor y el objeto receptor.
El objeto emisor solamente conoce los mtodos a los que puede
llamar del objeto receptor, por lo tanto, la dependencia entre el
objeto emisor y el objeto receptor est determinada por la interfaz
del objeto receptor.
Un objeto emisor se adhiere a la interfaz de un objeto receptor sin
que tenga que conocer los detalles de la implementacin de dicha
interfaz.
Se puede modificar la implementacin de un objeto receptor y no
afectar la dependencia con el objeto emisor ya que la interfaz del
objeto receptor se mantiene sin cambios.
Esto representa un beneficio para grandes sistemas que requieren
mantenimiento a lo largo de su vida.

Programacin Orientada a Objetos De las Heras, Sebastin | 15

Abstraccin vs. Encapsulamiento

Es necesario tener en cuenta lo siguiente: el Encapsulamiento es
frecuentemente confundido con la Abstraccin, pero son conceptos
distintos. Ambos conceptos estn relacionados y se complementan pero
representan ideas distintas.
Abstraccin:
La abstraccin es un proceso en el cual se identifican las
caractersticas y el comportamiento relevantes de un objeto.
Los agentes externos solamente conocen la interfaz del objeto.
La abstraccin provee al usuario lo que necesita conocer.

Encapsulamiento:
El Encapsulamiento es el mecanismo por medio del cual se
implementa la abstraccin. Es el resultado de la abstraccin.
El Encapsulamiento oculta los datos del objeto y el usuario no tiene
acceso a los mismos.
Da como resultado una menor dependencia entre objetos.

Para finalizar los conceptos relacionados al Encapsulamiento vamos a

mencionar algunas ventajas de esta caracterstica del Paradigma
Orientado a Objetos:
Mejora la seguridad de un sistema ya que los detalles internos de
la implementacin de un objeto permanecen ocultos para el resto de
los objetos.
La separacin entre la
implementacin permite
organizacin del sistema.

interfaz de un objeto y su
un mejor entendimiento y

Facilita el mantenimiento del sistema ya que podemos modificar

la implementacin de una clase sin alterar la interfaz de la misma.

Programacin Orientada a Objetos De las Heras, Sebastin | 16

1.4.3- Herencia
Concepto
Pensemos en los objetos que nos rodean. Muchos de ellos comparten
caractersticas comunes. Por ejemplo, podemos pensar en las
caractersticas que tienen los alumnos y los profesores:
Alumno:
-

Nombre

Apellido

Edad

Direccin

Legajo

Carrera

Fecha de ingreso

Profesor:
-

Nombre

Apellido

Edad

Direccin

Materia

Como podemos ver, hay un conjunto de caractersticas que tienen en comn

tanto los alumnos como los profesores:
-

Nombre

Apellido

Edad

Direccin

El Paradigma Orientado a Objetos permite que una clase herede

atributos y comportamiento comunes a otra clase. En el ejemplo anterior,
un objeto alumno es una instancia de la clase Alumno y un objeto profesor
es una instancia de la clase Profesor:

Programacin Orientada a Objetos De las Heras, Sebastin | 17

Alumno
Atributos
Nombre
Apellido
Edad
Direccin
Legajo
Carrera
Fecha de ingreso

Profesor
Atributos
Nombre
Apellido
Edad
Direccin
Materia

Pero tanto la clase Alumno como la clase Profesor, comparten atributos

que son comunes a todas las personas. Podemos definir entonces la clase
Persona con los siguientes atributos:

Persona
Atributos
Nombre
Apellido
Edad
Direccin
La clase Persona es ahora la superclase de las clases Alumno y Profesor, y
ambas heredan los atributos de la clase Persona (nombre, apellido, edad,
direccin). De esta forma, nuestro modelo de clases queda de la siguiente
manera:

Un objeto de la clase Alumno o Profesor tendr los atributos definidos en la

clase Persona. Esto tambin se aplica a los mtodos. Supongamos que la

Programacin Orientada a Objetos De las Heras, Sebastin | 18

clase Persona tiene los mtodos leer, caminar y correr. Las clases Alumno
y Profesor heredan tambin stos mtodos.
Esta caracterstica del Paradigma Orientado a Objetos de heredar
propiedades de otra clase se denomina Herencia.
La Herencia es un mecanismo que permite que una clase
defina sus propios atributos y mtodos, y tambin pueda
heredar atributos y mtodos de otras clases.
Cuando creamos un objeto alumno, tendr los atributos y mtodos propios
de la clase Alumno, pero tambin tendr los atributos y mtodos de la clase
Persona.
El mecanismo de herencia, produce una relacin de padre-hija en la
cual la clase hija reusa los atributos y mtodos definidos en la clase
padre, pero tambin la clase hija puede definir sus propios atributos y
mtodos.
En el desarrollo de un problema usando el Paradigma Orientado a Objetos,
algunas de las clases definidas se pueden dividir en clases ms especficas,
logrando de esta forma que clases ms generales se dividan en subclases.
La clase que es dividida se la conoce como superclase o clase
padre de las clases especficas.
A las clases ms especficas se las conoce como subclases o
clases hijas de la clase ms genrica.
A las relaciones de herencia tambin se las denomina relaciones de
extensin o generalizacin. La clase Alumno hereda o extiende los
atributos y mtodos de la clase Persona.
Cuando una clase A hereda las propiedades de otra clase, toma el
comportamiento de la clase inmediatamente superior, pero en el caso que
esta ltima sea hija de otra superclase, y sta de otra, y as sucesivamente,
entonces la clase A hereda las propiedades de todas estas clases superiores.
Las subclases se pueden dividir en otras subclases. La definicin de una
subclase se basa en la definicin de la superclase de la cual extiende y puede
especificar su propio conjunto de atributos y mtodos nicos a la subclase.
Un objeto o instancia de una subclase no slo contiene los atributos y
mtodos definidos en la subclase, sino que tambin hereda los atributos y
mtodos definidos en la superclase.
Las relaciones de herencia entre las distintas clases de nuestro modelo dan
forma a un rbol de herencia o rbol jerrquico:

Programacin Orientada a Objetos De las Heras, Sebastin | 19

Clase A

Clase B1

Clase C

Clase B2

Clase D1

Clase D2

Del rbol de herencia anterior hacemos el siguiente anlisis:

La clase A es dividida en dos subclases: B1 y B2.
La clase B1 contiene una subclase: C.
La clase B2 contiene dos subclases: D1 y D2.
Todos los objetos de la clase C contienen los atributos y mtodos
definidos en la clase C, pero tambin heredan los atributos y
mtodos definidos en las clases B1 y A.
Los objetos de la clase D1 contienen los atributos y mtodos
definidos en la clase D1, pero tambin heredan los atributos y
mtodos definidos en las clases B2 y A.
Los objetos de la clase D2 contienen los atributos y mtodos
definidos en la clase D2, pero tambin heredan los atributos y
mtodos definidos en las clases B2 y A.
Se debe tener en cuenta que cualquier objeto creado hereda las propiedades
definidas en la clase A, pero no todos los objetos contienen las propiedades
de todas las clases definidas en el rbol. Por ejemplo, un objeto de la clase
D2 no contiene las propiedades definidas en las clases C, B1 o D1.
Otra mencin a tener en cuenta es que un objeto puede ser una instancia de
ms de una clase. Por ejemplo, si tenemos un objeto de la clase C, este
objeto no slo es una instancia de la clase C, tambin es una instancia de la
clase B1 y de la clase A. Bajo esta consideracin, podemos decir que un
objeto de la clase C es tambin un objeto de la clase B1 y es tambin un
objeto de la clase A.
Vamos a describir los conceptos anteriores utilizando un ejemplo ms
concreto.

Programacin Orientada a Objetos De las Heras, Sebastin | 20

Supongamos que tenemos la clase Vehculo. De qu forma podemos

dividir esta clase en subclases? Podemos hacer la siguiente divisin:

Vehculo

Vehculo No
Motorizado

Bicicleta

Vehculo
Motorizado

Auto

Camin

Del presente rbol jerrquico podemos hacer el siguiente anlisis:

Todo objeto perteneciente a este modelo es un Vehculo, es decir,
todo objeto es una instancia de la clase Vehculo.
La clase Vehculo es la clase de mayor jerarqua del rbol.
La clase Vehculo es dividida en dos subclases: Vehculo
Motorizado y Vehculo No Motorizado.
La clase Vehculo No Motorizado contiene una subclase:
Bicicleta.
La clase Vehculo Motorizado contiene dos subclases: Auto y
Camin.
Un objeto de la clase Bicicleta contiene los atributos y mtodos
definidos en la clase Bicicleta, pero tambin hereda los atributos y
mtodos definidos en la clase Vehculo No Motorizado y la clase
Vehculo.
Un objeto del tipo Bicicleta es un Vehculo No Motorizado y es
un Vehculo, es decir, no solamente es una instancia de la clase
Bicicleta, tambin es una instancia de la clase Vehculo No
Motorizado y es una instancia de la clase Vehculo.
Un objeto de la clase Auto contiene los atributos y mtodos
definidos en la clase Auto, pero tambin hereda los atributos y
mtodos definidos en la clase Vehculo Motorizado y la clase
Vehculo.

Programacin Orientada a Objetos De las Heras, Sebastin | 21

Un objeto de tipo Auto es un Vehculo Motorizado y es un

Vehculo, es decir, no solamente es una instancia de la clase
Auto, tambin es una instancia de la clase Vehculo Motorizado y
es una instancia de la clase Vehculo.
Un objeto de la clase Camin contiene los atributos y mtodos
definidos en la clase Camin, pero tambin hereda los atributos y
mtodos definidos en la clase Vehculo Motorizado y la clase
Vehculo.
Un objeto del tipo Camin es un Vehculo Motorizado y es un
Vehculo, es decir, no solamente es una instancia de la clase
Camin, tambin es una instancia de la clase Vehculo
Motorizado y es una instancia de la clase Vehculo.

La herencia es una caracterstica importante que se agrega en el Paradigma

Orientado a Objetos.
Por medio de la Herencia se hace uso de una clase para tomar sus
propiedades y poder utilizarlas en clases ms especializadas.
Las relaciones de herencia no se limitan a un solo nivel, tambin se pueden
extender a varios niveles. Esto da como resultado un rbol jerrquico en el
que a medida que descendemos por el mismo, las clases son ms especficas
y van especializndose debido a que vamos agregando nuevos atributos y
mtodos en las clases ms especficas.

Programacin Orientada a Objetos De las Heras, Sebastin | 22

Redefinicin de mtodos
Supongamos que tenemos el siguiente modelo de clases:

Figura

Cuadrado

Rectngulo

Tringulo

La clase Figura tiene definido el mtodo calcular superficie.

Las subclases Cuadrado, Rectngulo y Tringulo heredan el mtodo

calcular superficie de la clase Figura.

El mtodo calcular superficie devuelve un nmero entero como

resultado de multiplicar el ancho por el alto de la figura
correspondiente.

Hay algn problema con esta estructura? Qu pasara si se ejecuta el

mtodo calcular superficie para un objeto de tipo Tringulo?
Claramente, el valor devuelto por el mtodo calcular superficie ser
incorrecto. La clase Tringulo hereda el mtodo calcular superficie de la
clase Figura, pero dicho mtodo se basa en la multiplicacin del ancho por
el alto de la figura. El clculo de la superficie de un tringulo est
determinado por la multiplicacin del ancho por el alto de la figura divido
dos.
Qu se puede hacer en este caso, para que se pueda ejecutar el mtodo
calcular superficie sobre un objeto de tipo Tringulo y el valor devuelto
sea correcto?
Lo que podemos hacer es sobrescribir o redefinir el mtodo calcular
superficie en la clase Tringulo:
-

Se define un mtodo en la clase Tringulo con el mismo nombre y

estructura (calcular superficie) al que se encuentra en la clase
Figura.

La implementacin del mtodo calcular superficie en la clase

Tringulo ser distinta a la implementacin definida en la clase
Figura. En este caso la implementacin de la clase Tringulo se
basar en el clculo de la multiplicacin del ancho por el ancho
dividido dos.

Programacin Orientada a Objetos De las Heras, Sebastin | 23

Lo que acabamos de hacer es redefinir el mtodo calcular superficie de la

superclase Figura. Qu logramos con esto? La prxima vez que se ejecute
el mtodo calcular superficie sobre un objeto de tipo Tringulo, el
mtodo ejecutado ser el que est definido en la clase Tringulo y no el de
la clase Figura, obteniendo como resultado el clculo correcto de la
superficie del objeto de tipo Tringulo.
La redefinicin de mtodos permite que una subclase o clase
hija sobrescriba un mtodo definido en la superclase o clase
padre. La implementacin definida en la clase hija sobrescribe
la implementacin de la clase padre.

A travs de este mecanismo, se pueden redefinir comportamientos que

son especficos a una subclase de acuerdo a las necesidades de los
requerimientos.
Para sobrescribir un mtodo en una subclase, el mtodo sobrescrito debe
tener la misma firma que el mtodo de la superclase (mismo nombre,
mismos parmetros y mismo tipo de dato a devolver).

Programacin Orientada a Objetos De las Heras, Sebastin | 24

Herencia mltiple
Hasta el momento, el tipo de herencia que hemos descripto en los ejemplos
corresponde a un tipo de herencia denominada Herencia simple. En
este tipo de herencia, las clases pueden heredar en forma directa (la clase
inmediatamente superior) los atributos y mtodos de solamente una clase
superior y no de ms de una clase. Por ejemplo, en nuestro rbol jerrquico
de vehculos, un auto hereda las propiedades definidas en las clases
Vehculo Motorizado y Vehculo, pero en forma directa solamente
hereda las propiedades de la clase Vehculo Motorizado, es decir, tiene
solamente una clase inmediatamente superior.
Analicemos el siguiente rbol jerrquico de clases:

Vehculo

Vehculo
Dos Ruedas

Bicicleta

Vehculo
Motorizado

Moto

Auto

En este modelo, hemos decidido dividir a la clase Vehculo en dos

subclases: la clase Vehculo Dos Ruedas y la clase Vehculo Motorizado.
Qu lugar ocupa en el modelo la clase Moto?
Es una moto un vehculo con dos ruedas? S, entonces la clase
Moto es una subclase de Vehculo Dos Ruedas.
Es una moto un vehculo motorizado? S, entonces la clase
Moto es una subclase de Vehculo Motorizado.
Cuntas superclases directas tiene la clase Moto? Dos:
Vehculo Dos Ruedas y Vehculo Motorizado.

Se trata de un ejemplo de Herencia Mltiple porque la clase Moto

hereda propiedades en forma directa de ms de una clase.

Programacin Orientada a Objetos De las Heras, Sebastin | 25

Uno de los problemas asociados a la Herencia Mltiple se da cuando las

clases padres tienen una funcin con la misma firma (mismo nombre y
mismos parmetros). Si la clase hija llama a esta funcin, entonces qu
funcin de las clases padres se ejecutar? Debido a estos posibles
escenarios, la herencia mltiple es ms compleja que la herencia simple.
Algunos lenguajes de programacin como C++ soportan el uso de
Herencia mltiple pero la complejidad que se agrega con este tipo de
herencia hace que no sea recomendable su uso.
Otros lenguajes de programacin como Java, soportan solamente la
Herencia simple para evitar la complejidad que puede generar el uso de
Herencia mltiple. Pero esto no es ningn limitante para Java, ya que
aquellos modelos que hacen uso de Herencia mltiple se pueden
redisear o hacer uso de otras caractersticas para solucionar el problema.

Programacin Orientada a Objetos De las Heras, Sebastin | 26

Ventajas de la Herencia
El uso de Herencia en el Paradigma Orientado a Objetos proporciona las
siguientes ventajas:
Desarrollo de modelos ms naturales e intuitivos por medio de
relaciones jerrquicas.
Reutilizacin de cdigo: cuando se crea una nueva clase
derivada, la misma contiene las propiedades definidas en su clase
padre sin la necesidad de tener que reescribir el mismo cdigo que
represente dichas propiedades. Solamente es necesario hacer
referencia a la clase padre. De esta forma se logra un ahorro de
tiempo y esfuerzo.
Extensibilidad: a partir del desarrollo inicial de una clase base se
pueden desarrollar clases ms especficas o con nuevas
funcionalidades en cualquier momento que sea necesario.

La Herencia es una caracterstica importante para la resolucin de

problemas utilizando el Paradigma Orientado a Objetos. La Herencia nos
permite descomponer un concepto en varias partes y niveles jerrquicos
logrando una mayor organizacin del problema.
Por otro lado, el uso de esta caracterstica mejora la reutilizacin de
cdigo ya que evita tener que definir varias veces el mismo conjunto de
atributos y mtodos que son comunes a varias clases.
Observe la siguiente figura con las dos clases expuestas:

Puede detectar algunos atributos que ambas clases tengan en comn?

Ambas clases tienen en comn los siguientes atributos:
-

Material

Alto

Ancho

Largo

Programacin Orientada a Objetos De las Heras, Sebastin | 27

Estos atributos en comn se encuentran definidos en cada una de las clases,

por lo tanto, la definicin de estos atributos se repite para cada una de las
clases.
Puede pensar de qu forma se puede hacer uso del mecanismo de Herencia
para las clases anteriores?
Podramos pensar en definir una superclase Mueble que contenga los
atributos que tienen en comn las clases Silla y Escritorio.

Con este nuevo modelo de clases, logramos definir la implementacin de los

atributos y mtodos que ambas clases tienen en comn solamente una vez y
no mltiples veces, ahorrando tiempo y esfuerzo.

Otro beneficio del uso de Herencia es el de extensibilidad. Qu se

entiende por esto? La extensibilidad es la propiedad que tiene un sistema
para poder adaptarse a futuros cambios que impliquen
modificaciones o un mayor crecimiento del sistema. Un sistema con
un buen nivel de extensibilidad es aquel que considera posibles
modificaciones del sistema y proporciona la base para implementar estas
modificaciones sin impactar en gran medida el resto del sistema. Un
modelo de clases que implementa correctamente el mecanismo de herencia
tiene un mayor soporte para la extensibilidad del modelo.
Analicemos el
extensibilidad.

siguiente

ejemplo

para

entender

el

concepto

de

Supongamos que el siguiente modelo de clases se corresponde al de un

sistema de ventas de un local que comercializa televisores y notebooks.

Programacin Orientada a Objetos De las Heras, Sebastin | 28

Producto

Televisor

Notebook

Los televisores y notebooks son productos que tienen atributos en comn y

por ello se ha definido la superclase Producto que contiene estos atributos
en comn. Las clases Televisor y Notebook extienden de la clase Producto.
En un momento dado, el dueo del local decide involucrarse en la venta de
equipos celulares. Cmo impacta esta decisin en nuestro modelo de
clases? Es en este momento en el que la extensibilidad del sistema se pone a
prueba. Si debemos realizar varias modificaciones en el sistema, y si
adems estas modificaciones repercuten sobre las clases existentes o se
debe redisear el modelo de clases, entonces decimos que el sistema tiene
un pobre nivel de extensibilidad. Pero si al contrario, las modificaciones a
realizar no tienen un alto impacto sobre el resto del sistema, entonces existe
un buen nivel de extensibilidad.
Nuestro nuevo modelo de clases quedara de la siguiente manera:

Producto

Televisor

Notebook

Celular

En este caso, solamente fue necesario agregar una nueva clase hija desde la
clase Producto y no se produjo ninguna alteracin sobre el resto de las
clases existentes. Al contar en nuestro modelo con una clase base que
representa cualquier tipo de producto, si en el futuro necesitamos agregar
ms tipos de productos, simplemente se extiende una nueva clase hija
desde la clase Producto.

Programacin Orientada a Objetos De las Heras, Sebastin | 29

Un modelo de clases bien diseado en donde las relaciones jerrquicas

estn debidamente establecidas, tiene una mayor predisposicin para
adoptar la extensibilidad del modelo.

La Herencia es una propiedad importante del Paradigma Orientado a

Objetos por medio de la cual una clase adquiere las propiedades definidas
de otra clase. Si esta propiedad es utilizada correctamente se pueden
obtener grandes ventajas que hacen que nuestro sistema sea ms flexible y
organizado.

Programacin Orientada a Objetos De las Heras, Sebastin | 30

1.4.4- Polimorfismo
Concepto
Literalmente, la palabra polimorfismo significa muchas formas. En la
Programacin Orientada a Objetos, el Polimorfismo es una caracterstica
que indica la habilidad de los objetos de comportarse de distintas
maneras ante un mismo mensaje.
La interaccin entre objetos se da por medio de mensajes y la respuesta de
un objeto est determinada por la ejecucin de alguna de sus acciones de
acuerdo al mensaje que reciba.
El Polimorfismo es una propiedad del Paradigma Orientado a
Objetos que permite obtener distintas respuestas de diferentes
objetos ante un mismo mensaje que les fue enviado.
Es decir, se trata de un mismo mensaje que origina una accin en un objeto,
pero la respuesta que se recibe puede variar dependiendo del objeto que
reciba el mensaje.
Analicemos el siguiente ejemplo para comprender esta caracterstica.
Supongamos que tenemos dos clases: Monitor e Impresora. Ambas clases
tienen definido el mtodo mostrar informacin. Si tuviramos un objeto
de tipo Monitor y ejecutramos el mtodo mostrar informacin, la accin
resultante sera la visualizacin de la informacin que se est manejando
sobre la pantalla del monitor.
Por otro lado, si tuviramos un objeto de tipo Impresora, el resultado de la
ejecucin del mtodo mostrar informacin sera la impresin de la
informacin sobre una hoja de papel.

Informacin
en
pantalla
mostrar
informacin

Objeto
emisor

Hoja
impresa

Programacin Orientada a Objetos De las Heras, Sebastin | 31

Qu conclusin podemos definir del ejemplo anterior?

En el Paradigma Orientado a Objetos, la ejecucin de una operacin
(mensaje) sobre distintos objetos, puede originar distintos resultados
dependiendo del objeto que reciba el mensaje.
En el ejemplo anterior, la ejecucin del mtodo mostrar informacin
genera distintos resultados dependiendo si quien recibe el mensaje es el
objeto monitor o el objeto impresora.
El objeto que enva el mensaje no necesita saber qu tipo de objeto es quien
recibe el mensaje. Solamente sabe que tiene un conjunto de objetos quienes
pueden aceptar el mensaje mostrar informacin y cada uno de ellos sabr
qu debe hacer ante este mensaje. Si una persona es el objeto que enva el
mensaje mostrar informacin, entonces esta persona no necesita conocer
si el objeto que recibe el mensaje es un monitor o una impresora,
solamente desea mostrar su informacin y para ello sabe que dispone de un
conjunto de objetos que pueden aceptar el mensaje mostrar informacin.
Vamos a mencionar otro ejemplo que haga uso del polimorfismo. En el
siguiente ejemplo tenemos los siguientes objetos: un perro, un caballo, una
vaca, una gallina y un len.
Cmo respondern estos objetos ante el mensaje emitir sonido? Si el
mensaje es recibido por:

El perro, entonces el sonido emitido ser un ladrido.

El caballo, entonces el sonido emitido ser un relincho.

La vaca, entonces el sonido emitido ser un mugido.

La gallina, entonces el sonido emitido ser un cacareo.

El len, entonces el sonido emitido ser un rugido.

Ante el mismo mensaje (emitir sonido), el resultado obtenido depende del

animal que reciba el mensaje.
La caracterstica del polimorfismo hace referencia entonces a que un mismo
mensaje puede generar distintos comportamientos en diferentes objetos.

Programacin Orientada a Objetos De las Heras, Sebastin | 32

Ventajas del Polimorfismo

El Polimorfismo ofrece las siguientes ventajas:
Reduce la dependencia entre objetos. El objeto emisor que enva
el mensaje hacia otro objeto, no necesita saber a qu clase pertenece
el objeto receptor, simplemente sabe que quien recibe el mensaje
puede aceptar su mensaje.
Favorece a la extensibilidad del sistema. Volvamos al primer
ejemplo en donde tenamos un objeto monitor y un objeto
impresora. Supongamos que deseamos agregar un objeto que
represente un proyector que me permita mostrar cierta informacin
mediante la proyeccin de imgenes. Simplemente lo que debemos
hacer es agregar una clase (Proyector) en el modelo que implemente
el mtodo mostrar informacin. Para cumplir con este nuevo
requerimiento, no es necesario alterar el resto del sistema,
simplemente se agrega una nueva clase que implementa el mtodo
mostrar informacin. Si se enva el mensaje mostrar
informacin, habr tres posibles comportamientos dependiendo si
quien recibe el mensaje es un monitor, una impresora o un
proyector.

Programacin Orientada a Objetos De las Heras, Sebastin | 33

1.4.5- Ventajas de la
Programacin
Orientada a Objetos
La utilizacin del Paradigma Orientado a Objetos presenta las siguientes
ventajas:

Modularidad
Una de las mayores ventajas del Paradigma Orientado a Objetos es la
modularidad, y por ello es uno de los principales objetivos buscados por
cualquier diseador de aplicaciones.
De la forma ms simple, podramos considerar un mdulo como un bloque
de cdigo, pudiendo ser este bloque un mtodo, una clase, un
componente, un servicio externo, etc. cuya misin es la ejecucin de una
funcionalidad especfica. El nivel de modularidad de un sistema va a estar
determinado por el nmero de mdulos que lo componen y la interaccin
que existe entre los mdulos.
La modularidad en el desarrollo de una aplicacin ofrece los siguientes
beneficios:
Se puede resolver un problema como una divisin en
subproblemas ms pequeos y de menor complejidad, siendo
cada una de estas divisiones un mdulo.
Si es necesario aplicar un cambio, solamente se aplica a un mdulo o
a un grupo reducido de mdulos, disminuyendo de esta forma el
impacto en el resto del sistema.
Facilita el entendimiento del sistema, ya que para entender un
mdulo no es necesario examinar los detalles de la implementacin
del resto de los mdulos. Es suficiente con conocer el propsito de
cada mdulo.
Se pueden realizar pruebas sobre un mdulo o un grupo de
mdulos independientemente del resto del sistema.
La modularidad en el desarrollo de una aplicacin ofrece una forma
de razonar ms natural e intuitiva en comparacin a otros
paradigmas. La forma de resolver un problema en el Paradigma
Orientado a Objetos se acerca a la forma de pensar de las personas.
Un objeto puede ser visto como un mdulo que encapsula las
caractersticas de una entidad de la realidad.

Programacin Orientada a Objetos De las Heras, Sebastin | 34

Facilidad de mantenimiento
El desarrollo modular del Paradigma Orientado a Objetos facilita el
mantenimiento del sistema. Por ejemplo, si realizamos una modificacin
en una superclase, el cambio se va replicar en las subclases sin necesidad de
reescribir el mismo cdigo en las subclases.
Por otro lado, si se modifica el cdigo de una clase que no tiene subclases, el
cambio se mantiene aislado a esa nica clase reduciendo de esta forma el
impacto en el resto de las clases.

Extensibilidad
La gran mayora de los sistemas sufren alteraciones a lo largo de su vida.
Estas alteraciones se deben entre otras cosas al entorno cambiante en el que
se desenvuelve el sistema. Nuevos requerimientos con nuevas
funcionalidades pueden surgir, razn por la cual es deseable que nuestro
sistema sea lo suficientemente flexible para dar soporte a las nuevas
funcionalidades sin alterar el resto del sistema.
El Paradigma Orientado a Objetos permite el diseo de sistemas
extensibles. La caracterstica de Herencia da soporte al crecimiento de un
programa sin modificar las clases existentes. Si se desea agregar una nueva
funcionalidad representada en una subclase, simplemente se la agrega en el
modelo de clases y se indica la relacin de extensin con su clase padre,
permaneciendo el resto de las clases sin modificarse.
Este beneficio es dependiente del diseo del sistema, por lo que es
importante definir un buen modelo de clases con la correcta definicin de
la jerarqua de clases. Si logramos un buen diseo podremos:

Agregar nuevas clases y subclases.

Agregar nuevos atributos y mtodos en las clases existentes.

Reutilizacin
Cuando desarrollamos un sistema, resulta interesante que los mdulos que
vamos desarrollando estn disponibles para su utilizacin tantas veces
como sea necesario cuando se los necesite.
Los conceptos inherentes al Paradigma Orientado a Objetos son totalmente
propicios para la reutilizacin de cdigo. Pero cmo logramos reutilizar
cdigo en el desarrollo de un programa? El Paradigma Orientado a Objetos
me permite reutilizar cdigo mediante el encapsulamiento de una
funcionalidad en un mdulo, ya sea mediante un mtodo, una clase, un
paquete, un componente, etc. De esta forma, se puede llamar a dicho
mdulo cuantas veces sea necesario cada vez que se lo necesite.

Programacin Orientada a Objetos De las Heras, Sebastin | 35

El concepto de clases como contenedores de cdigo que proveen alguna

funcionalidad especfica, nos permite hacer uso de las mismas cuantas
veces sea necesario en diferentes escenarios. Se evita as, reescribir
nuevamente todo el cdigo que hace referencia a la funcionalidad de la clase
donde se desea usarla.
Por ejemplo, si hemos definido en algn momento la clase Persona para
hacer uso de ella en una aplicacin de gestin de empleados, y en el
presente momento estamos construyendo una aplicacin para la facultad y
es necesario definir la misma clase, no es necesario tener que definir
nuevamente la clase Persona. Podemos reusar la clase que hemos definidos
con anterioridad.
Como los mdulos que podemos desarrollar pueden ser reutilizados en
otros escenarios, es importante que los mismos sean legibles y entendibles
ya que otros programadores pueden hacer uso de los mismos.
El empleo de libreras tambin facilita la reutilizacin. Si necesitamos
emplear alguna funcionalidad disponible en algn componente de una
librera, simplemente es suficiente con importar dicha librera y hacer uso
del componente.
Para qu gastar esfuerzo y tiempo en algo que ya han hecho otras
personas? Por ello es que usamos la reutilizacin.
La Herencia tambin es una caracterstica que facilita la reutilizacin de
cdigo. Cuando definimos una clase padre con algn mtodo en particular,
dicho mtodo forma parte de las subclases, es decir no es necesario tener
que reescribir el mismo mtodo en las subclases.
Mediante la reutilizacin de mdulos se logra:
Reducir los tiempos de desarrollo.
Lograr mayor consistencia.
Facilitar las tareas de mantenimiento.
Reducir la cantidad de cdigo de un programa.
Eliminar la redundancia de cdigo.
Desarrollar modelos ms naturales.
La resolucin de problemas utilizando el Paradigma Orientado a Objetos
define modelos ms naturales y cercanos a la forma de pensar del hombre
que cualquier otro paradigma.
El Paradigma Orientado a Objetos modela objetos del mundo real. Los
modelos de resolucin de un problema cuentan con un conjunto de objetos
que interactan entre s de la misma forma que entidades del mundo real se
comunican entre s. De la misma forma que en el mundo real las entidades
tienen relaciones jerrquicas, en el POO los objetos tambin estn
organizados jerrquicamente por medio de relaciones de herencia.

Programacin Orientada a Objetos De las Heras, Sebastin | 36

Bibliografa Lectura 2
Booch Grady, (2007), Object-Oriented Analysis and Design with Applications
(3a ed.), EE.UU, Editorial Addison-Wesley.
Rumbaugh James, (1999), Modelado y Diseo Orientado a Objetos, Espaa,
Editorial Librisite.
Bruce Eckel, (2006), Thinking in Java (4a ed.), EE.UU, Editorial Prentice Hall.
Bertrand Meyer, (1997), Object-Oriented Software Construction (2a ed.),
EE.UU, Editorial Prentice Hall.
Wikipedia, (2011), Abstraccin (informtica), Recuperado el 07/05/2011 de
http://es.wikipedia.org/wiki/Abstracci%C3%B3n_%28inform%C3%A1tica%29

Programacin Orientada a Objetos De las Heras, Sebastin | 37