Pid 00161674

Introduccin
a la orientacin
a objetos
Jordi Brnquez Jimnez
Elena Garca Barriocanal
PID_00161674
FUOC PID_00161674 Introduccin a la orientacin a objetos
ndice
Introduccin ............................................................................................ 5
Objetivos ................................................................................................... 6
1. Los inconvenientes de la programacin clsica ........................ 7
2. La orientacin a objetos .................................................................. 9

2.1. El nacimiento de una manera nueva
de construir aplicaciones ................................................................ 9
2.2. Reutilizacin del cdigo ................................................................. 12
3. Lenguajes de programacin orientada a objetos ...................... 15

3.1. Evolucin histrica de los lenguajes de programacin .................. 15
3.2. Evolucin de los lenguajes de programacin orientada
a objetos .......................................................................................... 17
3.3. Caractersticas bsicas de los lenguajes de programacin
orientada a objetos ......................................................................... 18
Resumen .................................................................................................... 21
Ejercicios de autoevaluacin ............................................................... 23
Solucionario ............................................................................................. 24
Glosario ..................................................................................................... 24
Bibliografa .............................................................................................. 25
FUOC PID_00161674 5 Introduccin a la orientacin a objetos
Introduccin
En este mdulo, pretendemos proporcionar una visin genrica y global de la

orientacin a objetos que permita a los estudiantes empezar a familiarizarse
con los conceptos en los que profundizaremos durante la asignatura.
El presente mdulo se divide en tres grandes bloques, que incluyen los temas si-
guientes:
1) Las dificultades que encontraban los programadores a la hora de hacer apli-

caciones y mantener operativos los desarrollos durante los aos sesenta. En
este bloque repasamos las causas principales de la crisis del software, derivadas
tanto de la complejidad inherente a las aplicaciones como de las dificultades
que rodean su construccin.
2) La gnesis de la orientacin a objetos y cmo, desde que naci, se orient

a resolver los problemas que haba en el mbito de la simulacin. Despus,
poco a poco, se extendi su uso a otros campos de aplicacin hasta llegar a los
aos noventa, cuando se generaliz. En este apartado, os mostramos, sin for-
malismos, el modelado orientado a objetos y las ventajas de esta manera de
construir aplicaciones.
3) Finalmente, os presentamos la evolucin de los lenguajes de programacin de

alto nivel. En esta evolucin, podemos ver que los lenguajes se ocupaban cada vez
ms de conceptos relacionados con la modularizacin y la abstraccin. Tambin
vemos que, con la orientacin a objetos, es necesario introducir conceptos nuevos
en los lenguajes de programacin para que stos soporten toda la potencia de este
paradigma. Para acabar, os mostramos cules son las caractersticas que deben te-
ner los lenguajes de programacin orientada a objetos.
Objetivos
Los materiales didcticos de este mdulo proporcionan los conocimientos

fundamentales para que los estudiantes alcancis los objetivos siguientes:
1. Conocer cmo naci el paradigma de la orientacin a objetos y qu proble-

mas intenta resolver.
2. Identificar la orientacin a objetos como una manera de resolver proble-

mas ms prxima al razonamiento humano y que refleja mejor el dominio
de la aplicacin que la programacin procedimental.
3. Conocer las ventajas principales de la orientacin a objetos, sobre todo con

respecto a la reutilizacin del cdigo.
4. Conocer las ventajas de disear y utilizar el cdigo reutilizable.
5. Conocer cmo han evolucionado los lenguajes de programacin de alto nivel.
6. Tener una visin general de conceptos relacionados estrechamente con la

orientacin a objetos, como el encapsulamiento, la herencia, la generici-
dad o el polimorfismo.
1. Los inconvenientes de la programacin clsica
A finales de la dcada de los sesenta, concretamente en 1968, se reconoci p-

blicamente en una conferencia organizada por la Comisin Cientfica de la
OTAN que haba un problema en el desarrollo de los sistemas de software que
haca que no fueran tan tiles como se esperaba. Concretamente, las aplica-
ciones que se construan, o bien no llegaban nunca a completarse con xito,
o bien, adems de ser muy costosas, su volumen y falta de estructuracin las
haca prcticamente imposibles de mantener y, por otra parte, escasamente
fiables. Esta situacin fue denominada con la expresin crisis del software.
Lectura recomendada
Las causas que dieron lugar a esta situacin tienen el origen en la comple-
F. P. Brooks (1987, abril).
jidad intrnseca de las aplicaciones, que deriva fundamentalmente de No Silver Bullet. Essences
and Accidents of Software
cuatro elementos que se pueden identificar en aplicaciones de mediana y Engineering. Computer
Magazine.
gran envergadura:
Si por s mismas las aplicaciones ya tratan de resolver problemas ciertamente

El anlisis
complejos, el equipo de desarrollo no suele tener claro desde el primer de requerimientos...
momento qu se espera de la aplicacin, ya que los usuarios no siempre ... es el proceso que se sigue
consiguen transmitir sus necesidades y expectativas. Esto obliga a realizar para identificar las tareas que
nuestro programa tiene que
multitud de cambios en los requisitos durante el desarrollo, lo cual dificulta realizar de las explicaciones
que los usuarios nos hacen so-
considerablemente este proceso. Si la captura de requisitos fuera eficiente y bre el problema y de los cono-
cimientos que nosotros
el usuario los pudiera verificar mediante prototipos en fases tempranas del podemos tener.
desarrollo, esta dificultad y el coste respectivo se reduciran.
La complejidad del dominio y de la solucin hace que haya que descom-

poner la aplicacin en gran cantidad de mdulos y, por lo tanto, que se re-
quieran grandes equipos de desarrollo. Hay que tener en cuenta que
hablamos de aplicaciones que modelan el mundo real. Esto comporta la di-
ficultad de gestionar un equipo de desarrollo con muchos miembros, man-
teniendo una unidad e integridad del diseo de la aplicacin.
Casi siempre que se construye una aplicacin, se identifican partes que se

podran resolver de manera parecida a como se hizo en aplicaciones an-
teriores, pero la ausencia casi absoluta de estndares en la industria del
software hace que aquello que ya se ha implementado sea difcilmente
reutilizable.
Y para acabar, caracterizar el comportamiento de sistemas discretos es muy

difcil. Estos sistemas pueden tener un nmero muy grande de estados y los
acontecimientos externos pueden afectar al estado interno del sistema. Por
este motivo, las pruebas no se pueden considerar nunca completas, ya que
es imposible simular todas las situaciones que pueden suceder.
Esta complejidad, unida a la falta de una metodologa a la hora de desarrollar

En el desarrollo
las aplicaciones, haca que los desarrollos basados en las estructuras de datos estructurado clsico...
clsicos presentaran los inconvenientes siguientes: ... se conciben las aplicaciones
como una funcin que, a partir
de unas entradas, obtiene unos
Limitaciones en el modelado de problemas no estructurados, ya que el m- resultados que se refinan suce-
sivamente en funciones ms
todo utilizado para construir las aplicaciones est basado en el hecho de especficas.
descomponer la aplicacin en una jerarqua de mdulos funcionales idea-
dos para transformar unas entradas determinadas en salidas bien definidas.
Este tipo de diseos no facilitan resolver problemas complejos desestructu-
rados. Se trata de un enfoque ms apropiado para resolver problemas es-
tructurados, en los que se puede describir el cdigo segn algoritmos de
transformacin de datos.
Reutilizacin difcil del cdigo, ya que los mdulos se caracterizaban por la

transformacin concreta de datos, cosa que lo haca muy dependiente de
la aplicacin original.
Mantenimiento difcil y costoso, ya que los mdulos estaban muy orienta-

dos a tratar los datos y normalmente, durante su desarrollo, no se tenan
en cuenta posibles cambios futuros.
Reduccin de la calidad de las aplicaciones, medida en flexibilidad, eficien-

cia, fiabilidad y robustez, criterios que trataremos en el mdulo siguiente.
La calidad se reduce a medida que se hacen modificaciones, ya que stas
complican cada vez ms el diseo original, con lo cual se resta flexibilidad
al desarrollo y cada vez resulta ms complejo introducir nuevos cambios.
2. La orientacin a objetos
La programacin orientada a objetos es una tcnica para construir aplicacio-

nes ms antigua de lo que puede parecer. Si bien pas desapercibida hasta
principios de la dcada de los noventa, su origen se remonta a 1967, cuando
dos noruegos, Ole-Johan Dahl y Kristen Nygaard, idearon los conceptos bsi-
cos de la programacin orientada a objetos tal y como se conoce hoy.
2.1. El nacimiento de una manera nueva de construir aplicaciones
Dalh y Nygaard trabajaban en un centro de clculo haciendo simuladores para

procesos industriales y cientficos. A la hora de llevar a cabo las simulaciones,
encontraron dos tipos de problemas fundamentales, adems de las dificulta-
des que cualquier desarrollo ya implicaba:
a) En cuanto al diseo del simulador, vieron que no slo era necesario tener
conocimientos de informtica para poder implementarlo, sino que adems se
necesitaba tener conocimientos amplios de ingeniera para identificar y espe-
cificar adecuadamente las caractersticas y el comportamiento del sistema real.
b) Con respecto a las modificaciones, vieron que el simulador se tena que

modificar continuamente hasta conseguir el funcionamiento deseado y, vista
la complejidad del sistema, las modificaciones eran extremadamente costosas.
Para superar estas dificultades, muy comunes en las aplicaciones que se En el mdulo Clases y objetos,
se definirn los conceptos de clase
desarrollaban en aquella poca, se plante hacer los simuladores con el y objeto que, aunque son diferentes,
los trataremos indistintamente en este
mdulo.
objetivo de que reflejaran los sistemas reales de la manera ms fiel posible. En
vez de construir aplicaciones monolticas, los mdulos simularan cada una de
las piezas necesarias, y stas se comunicaran entre s como lo hacen en el
mundo real.
Cada pieza se tendra que implementar como un mdulo, que se denomin

clase, y que tendra los valores necesarios para representar su estado, sus atributos
y un conjunto de rutinas que serviran para gestionar todas las seales que esta
pieza podra recibir de los otros mdulos, sus mtodos. Adems, tendra la capa-
cidad de comunicarse con los otros mdulos con los que estuviera relacionada,
ya que almacenara informacin sobre stos para poder enviarles seales.
A partir de lo que hemos explicado hasta ahora, podemos dar una primera de-
finicin informal de objeto:
Un objeto es una representacin de una entidad real (tangible o intangible), cuyo tipo es
una clase concreta que se caracteriza por unos valores concretos que representan su esta-
do y su comportamiento.
Con esta nueva manera de implementar el simulador, se solucionaron los dos

problemas principales que hemos comentado anteriormente.
Por una parte, los informticos ya no tenan que conocer a fondo el campo de
la ingeniera, sino que un ingeniero o fsico, por ejemplo, les proporcionara
la descripcin exacta del funcionamiento de cada pieza y ellos slo tendran
que implementar el comportamiento de la pieza de acuerdo con la especifica-
cin dada.
Por otra parte, las modificaciones resultaban mucho ms sencillas porque aho-
ra ya no haba que perder demasiado tiempo para localizar las partes afectadas
por los cambios, nicamente era necesario identificar la pieza en la que se te-
nan que realizar los ajustes y modificar su mdulo.
Observad que, en este enfoque, los mdulos corresponden a entidades reales

que en el caso del simulador son las piezas del sistema, no como hasta
ahora, que el concepto de mdulo se limitaba a agrupar ciertas funcionalida-
des del proceso al que eran sometidos los datos (captura de datos, clculos, ac-
tualizaciones, etc.).
Una vez expuesto cmo surgi la orientacin a objetos, podemos decir

que se trata de una manera nueva de resolver problemas ms ajustada
al mundo real y, por lo tanto, ms prxima al proceso mental de las
personas.
La orientacin a objetos est basada en tres aspectos organizativos prximos

al razonamiento humano, ya que establecen conexiones entre los elementos
siguientes:
Un objeto y sus caractersticas; por ejemplo, un coche tiene un color, un

nmero de puertas, etc.
Un objeto y otros objetos con los que se asocia (que al mismo tiempo se
relacionan con otros objetos); por ejemplo, el coche tiene unas ruedas (con
unas caractersticas propias), un motor, etc.
Un objeto y otros objetos que especializa; por ejemplo, un coche puede ser
deportivo o familiar, pero no puede ser un camin ni un avin.
Teniendo en cuenta todo lo que hemos explicado hasta ahora, podemos decir
que la orientacin a objetos va ms all de la implementacin de aplicaciones.
La orientacin a objetos define toda una filosofa para analizar y disear estas
aplicaciones.
Antes de empezar a implementar cualquier problema, es necesario examinar

qu requisitos hay desde la perspectiva de la programacin orientada a objetos
utilizando clases y objetos a partir del vocabulario del problema. Una vez ob-
tenido el modelo del problema, ser necesario refinar y adaptar el modelo al
lenguaje de programacin que se utilizar, dado que no todos los lenguajes
implementan los conceptos de la programacin orientada a objetos de la mis-
ma manera.
A continuacin, mostraremos un ejemplo que nos permitir comprobar las

diferencias entre el desarrollo orientado a objetos y el desarrollo procedi-
mental.
Problema
Tenemos que hacer una aplicacin para gestionar las nminas de los profesores de una
facultad y la dotacin econmica que recibe cada departamento.
En la facultad, cada profesor imparte docencia en una asignatura, cobra de acuerdo con
las horas impartidas y pertenece a un departamento.
Segn la carga docente, los departamentos tienen una dotacin econmica u otra.
Para nuestra aplicacin, necesitaremos saber los datos que modelan los departamentos
(nombre, director, secretario, direccin postal, los profesores que hay asignados, etc.) y
una operacin que nos diga cul es la dotacin econmica de los departamentos (para
evaluarla, necesitaremos saber el nmero de horas de docencia de todos sus profesores).
De los profesores, aparte de los datos identificadores (el nombre y los apellidos, el despa-
cho, el correo electrnico, etc.), necesitaremos poder consultar el nombre de las asigna-
turas que imparten y las horas de docencia que realizan en estas asignaturas.
De las asignaturas, habr que saber el nombre y las horas de docencia.
Solucin con el desarrollo clsico
Por una parte, tendramos que definir las estructuras de datos que necesitaramos en
nuestra aplicacin (departamento, profesor y asignatura) y, para cada una de stas, debe-
ramos definir una estructura de datos para almacenarlas todas.
Despus necesitaramos una estructura de datos que nos permitiera representar las rela-
ciones entre los departamentos y los profesores, y otra para representar la relacin entre
los profesores y las asignaturas.
Finalmente, tendramos que implementar las operaciones que nos permitieran realizar
las funcionalidades pedidas, y tambin otras operaciones que nos sirviesen para nave-
gar entre las relaciones almacenadas.
Solucin con el desarrollo orientado a objetos
En este caso, lo que tendramos que hacer es identificar cada entidad (departamento, pro-
fesor y asignatura) y utilizar tres mdulos diferentes en los que se definiran las propie-
dades de cada entidad y se implementaran las funcionalidades por separado.
Por ejemplo, en la operacin del departamento de clculo de las horas lectivas (para cal-
cular la asignacin), en vez de tener que navegar por toda la estructura de datos para sa-
ber si un profesor es o no del departamento, puesto que cada departamento ya est
relacionado con sus profesores, slo hara falta pedirles las horas lectivas y sumarlas.
Una vez definidas estas entidades en nuestra aplicacin de gestin, tendramos tantos ob-
jetos de tipo Profesor como profesores haya, cada uno de los cuales con los datos que
lo definen, y tantos objetos de tipo Departamento como departamentos haya en el sis-
tema.
En este caso, no sera necesaria una estructura que representara las relaciones, ya que los
objetos ya estn relacionados entre s.
A la vista del ejemplo anterior, podramos decir que la orientacin a ob-

jetos permite agrupar las funcionalidades referentes a un mismo tipo de
objeto en un mismo fichero y, por lo tanto, localizar posibles problemas
es mucho ms rpido y hacer modificaciones es ms sencillo.
Algunos argumentos para usar la programacin orientada a objetos son la me-

jora de la calidad de las aplicaciones, la escalabilidad y adaptabilidad de stas,
y tambin la disminucin del tiempo y el coste de desarrollo. Gran parte de
estas ventajas provienen de otra fundamental: el concepto de reutilizacin del
cdigo, que veremos en el apartado siguiente.
2.2. Reutilizacin del cdigo
Utilizando otra vez el ejemplo de los simuladores, podemos decir que es muy
frecuente que se aprovechen piezas de simulaciones anteriores a la hora de
construir simuladores para hardware nuevo. Sin embargo, vistas las tcnicas
que se utilizaban en la programacin clsica, el nico mecanismo de reutiliza-
cin posible era crear bibliotecas de funcionalidades que se podan invocar
desde diferentes simulaciones (programas).
Gracias a la programacin orientada a objetos, dado que cada pieza se

implementa como un elemento completo tiene unas propiedades y
mtodos propios de manera autocontenida y separado del resto, cual-
quier pieza se puede utilizar en diseos nuevos sin ninguna, o escasa,
modificacin.
Esta propiedad de poder utilizar elementos de software programados y probados

En el concepto de
previamente durante la construccin de aplicaciones nuevas se denomina reutilizacin de cdigo...
reutilizacin o reusabilidad. ... se supone que hay un repo-

sitorio de donde se pueden
tomar los mdulos ya imple-
Podemos resumir las ventajas principales que se obtienen de reutilizar un c- mentados.
digo en las siguientes:
Disminucin de los esfuerzos de mantenimiento. Puesto que todo el cdi-

go que afecta a una entidad est en un mismo mdulo, las tareas de man-
tenimiento se basan en modificaciones de aquel mdulo.
Ms velocidad en el desarrollo, favorecida principalmente por el hecho de

no tener que rehacer todo el trabajo.
Aumento de la fiabilidad de los programas. Ya que es un mdulo progra-

mado por una persona con conocimientos sobre la entidad que representa,
se puede crear una representacin mejor que si no se tienen estos conoci-

mientos.
Ms eficiencia, principalmente por las mismas razones que en el caso ante-

rior, ya que si se conoce bien la entidad, se puede optimizar mejor que si
no se conoce en profundidad.
Aumento de la consistencia de la aplicacin para usar componentes ms

fiables y eficientes.
Abaratamiento de costes favorecido por el hecho de no tener que realizar

tareas bsicas en cada proyecto, ya que se pueden aprovechar de proyectos
anteriores.
Para ejemplarizar mejor el concepto de reutilizacin de cdigo, podemos Las listas desplegables...
hablar de las interfaces grficas de usuario. Esta coleccin de elementos
... nos permiten seleccionar
que utilizamos cuando desarrollamos aplicaciones grficas (mens, botones, una opcin entre las que se
muestran cuando se despliega
cuadros de texto, etc.) no los programamos cada vez, sino que los tomamos la lista.
de un repositorio que los creadores del sistema operativo o el lenguaje de
programacin nos ofrecen. Si los tuviramos que implementar nosotros,
aparte de que deberamos tener un gran conocimiento sobre este tema,
necesitaramos mucho ms tiempo, ya que estos elementos los utilizamos
muchas veces en nuestro programa.
Los mens...
... nos permiten seleccionar di-

El desarrollo de los elementos de las interfaces grficas ha sido realizado por
ferentes acciones que hay que
un grupo de programadores una nica vez, y todos nosotros sacamos prove- realizar de entre las disponi-
bles.
cho del mismo. Por lo tanto, podemos decir que, en este caso, aprovechamos
los siguientes aspectos de la programacin orientada a objetos:
a) Eficiencia de nuestra aplicacin para tratar la interfaz grfica, ya que supo-

nemos que estos elementos son lo ms eficientes posible.
b) Fiabilidad de la interfaz grfica, ya que estos elementos estn muy proba-

dos y, por lo tanto, no presentarn un comportamiento inesperado.
c) Consistencia de la interfaz de usuario, dado que todos los elementos tienen

unas caractersticas parecidas.
d) Ms velocidad de desarrollo y menos costes. Como hemos comentado, estos

elementos ya nos vienen dados y, por lo tanto, ahorramos tiempo y dinero.
e) Eliminacin de los costes de mantenimiento, ya que estos elementos, pues-

to que ya estn hechos, no necesitan ni pueden ser modificados.
Como podemos ver, estos elementos pueden ser identificados como objetos,
ya que tienen un texto (el nombre del botn, el texto de los mens, etc.), un
estado (pulsado / no pulsado, activo / inactivo, etc.) y un comportamiento

(permiten la escritura de texto o de contraseas, la ordenacin de tablas, etc.).
Estas propiedades de la biblioteca grfica ya estn implementadas y estn dis-
ponibles para utilizarlas.
3. Lenguajes de programacin orientada a objetos
3.1. Evolucin histrica de los lenguajes de programacin
Los lenguajes de programacin han tenido grandes transformaciones durante

Las grandes
su historia. Hay muchas clasificaciones que, segn diferentes criterios, as lo transformaciones
muestran. Una de las ms conocidas es la clasificacin de Wegner, que divide La ampliacin del campo de
aplicacin de los programas, el
los lenguajes de programacin de alto nivel de acuerdo con el orden de
abaratamiento de los ordena-
aparicin y las caractersticas comunes. Concretamente, la clasificacin consta dores y de su potencia cada
vez ms elevada.
de lenguajes de primera generacin, de segunda generacin, de tercera
generacin y la generacin de los lenguajes actuales.
a) Lenguajes de primera generacin
Lenguajes que se desarrollaron entre 1954 y 1958. Con stos se produjo un sal-
to en la abstraccin a la hora de programar, ya que anteriormente se utilizaba
el lenguaje ensamblador, que requera un buen conocimiento de la mquina
en la que se ejecutara el cdigo. Algunos ejemplos de estos lenguajes son For-
tran I, Algol 58 o IPL V: todos estaban basados en expresiones matemticas y,
por lo tanto, su dominio de aplicacin estaba centrado en el clculo y las apli-
caciones cientficas y de ingeniera.
Los programas que se hacan con estos lenguajes se basaban en subprogramas

que compartan los datos al ser ejecutados.
Figura 1. Lenguajes de primera generacin
Esta situacin presentaba problemas serios porque cualquier error en el fun-

cionamiento de un subprograma se propagaba al resto de la aplicacin. Apar-
te, cuando el programa era demasiado grande, cualquier cambio se traduca en
una tarea muy costosa que no siempre se consegua llevar a cabo sin complicar
todava ms el diseo original.
b) Lenguajes de segunda generacin
Aparecieron a finales de la dcada de los cincuenta y a principios de los sesen-

ta. En estos lenguajes, se empez a poner nfasis en la abstraccin algortmica
y la programacin se extendi poco a poco a otros dominios del mundo real.
Algunos de los lenguajes pertenecientes a esta generacin son Cobol, Algol 60
o Fortran II.
En el terreno de la estructuracin de los programas, la segunda generacin em-

pieza a introducir el concepto de procedimientos dentro de los subprogramas,
con lo cual aparecen los conceptos de paso de parmetros y de visibilidad de
las variables.
Figura 2. Lenguajes de segunda generacin
c) Lenguajes de tercera generacin
Comprende los lenguajes creados entre 1962 y 1970. En esta poca, los costes
del hardware continan abaratndose, lo cual hace que las aplicaciones infor-
mticas lleguen cada vez ms a mbitos ms distintos. Esta diversificacin en los
campos de trabajo comporta que se tenga que trabajar con tipos de datos dife-
rentes de los puramente matemticos, y cambiantes de una aplicacin a otra.
Por este motivo, en esta poca aparece el concepto de tipo abstracto de datos,
que permite al programador especificar un tipo adecuado para cada problema
y dotarlo de significado mediante un conjunto de operaciones sobre este tipo
de dato.
Figura 3. Lenguajes de tercera generacin

Este nuevo concepto resuelve algunos problemas de la programacin de

aplicaciones grandes, ya que de esta manera distintos desarrolladores pue-
den implementar mdulos diferentes que se pueden compilar por separado
y, finalmente, combinarlos. A pesar de todo, durante esta poca el concep-
to de abstraccin de los datos no fue demasiado utilizado como tal, sino
que simplemente permita agrupar distintas funcionalidades en mdulos
diferentes.
Otro concepto que no exista era el de la visibilidad de los datos. Por lo tanto,
nada impeda que diferentes mdulos modificasen directamente los datos de
otros mdulos (en lnea discontinua en el diagrama anterior).
d) Lenguajes de cuarta generacin o actuales
Estos son lenguajes de programacin que no son de propsito general, como

los descritos anteriormente. Han sido diseados para algn propsito espec-
fico. Entre otros, estn Sculptor, Dbase, SAS y PHP.
3.2. Evolucin de los lenguajes de programacin

orientada a objetos
El primer lenguaje orientado a objetos fue SIMULA 67. Fue creado por cient-
ficos noruegos (Nygaard y Gahl) que, despus de probar otros lenguajes de ter-
cera generacin, decidieron crear un lenguaje que les permitiera realizar todo
lo que los otros no les permitan a causa de las limitaciones que tenan.
SIMULA 67 fue el primer lenguaje de programacin en el que se introdujeron

los conceptos de clase y objeto.
Ms tarde, a principios de los aos setenta, en los laboratorios de Xerox, un

equipo de desarrollo intent implementar un prototipo de ordenador para ni-
os, conocido como DynaBook, que utilizaba por primera vez el concepto de
interfaz grfica de usuario. Enseguida los desarrolladores relacionaron las
ideas de la programacin orientada a objetos con las piezas del ordenador nue-
vo, ya que se poda definir perfectamente el funcionamiento de cada elemento
grfico como un objeto, porque tena un comportamiento muy definido y res-
ponda a interacciones muy concretas.
Para implementar el proyecto DynaBook, elaboraron un lenguaje de programa-

cin nuevo denominado Smalltalk, que estaba fuertemente influido por SIMU-
LA 67. Este lenguaje introduca el concepto de herencia de manera explcita.
La herencia es el mecanismo que permite que un objeto comparta las caracte-

rsticas y el comportamiento de otro objeto, del cual se dice que hereda.
El concepto de herencia es muy valioso para reutilizar cdigo, ya que deter-

minados objetos, aunque no son idnticos, s que tienen caractersticas comu-
nes. Por ejemplo, toda persona tiene un nombre y una fecha de nacimiento.
Estas propiedades se utilizarn tanto si dentro de nuestra aplicacin la persona
es una estudiante como si es un profesor. En prximos mdulos, lo estudiare-
mos ms detalladamente.
A partir de este momento, los lenguajes de programacin orientada a objetos

van incorporando caractersticas nuevas que los hacen evolucionar hasta los
lenguajes de programacin que conocemos hoy en da.
En la dcada de los ochenta, Bjarne Stroustrup, empleado de AT&T Labs., am-

pli el lenguaje de programacin C para adaptarlo a la programacin orienta-
da a objetos. Inicialmente se denomin C with classes, pero finalmente se
llam C++. Este lenguaje est basado en el SIMULA 67, con respecto a la orien-
tacin a objetos, y en el C, en cuanto a la sintaxis.
Desde que aparecieron los lenguajes orientados a objetos, stos han ido apor-
tando funcionalidades nuevas a la programacin orientada a objetos en ver-
siones sucesivas, como las clases abstractas, los mtodos static o la genericidad.
Veremos todos estos conceptos en los prximos mdulos.
Actualmente hay muchos lenguajes de programacin orientada a objetos, unos

descendientes de lenguajes procedimentales que se han adaptado al paradigma
de la programacin orientada a objetos (POO) y otros que se han creado desde
el principio pensando en este paradigma. Por poner algunos ejemplos, aparte
de C++, SIMULA 67 y Smalltalk, que ya hemos mencionado antes, podemos
mencionar Perl 5, Python, Java, C#, Delphi, Eiffel, etc.
3.3. Caractersticas bsicas de los lenguajes de programacin

orientada a objetos
La mayora de los lenguajes de programacin orientada a objetos cumplen una

serie de caractersticas que nos permiten utilizar todo el potencial de la orien-
tacin a objetos:
Tipificacin estricta
ste es un concepto que, aunque no es especfico de la programacin orien-

tada a objetos, es necesario cumplir. Este hecho implica que si dos expre-
siones estn relacionadas, tanto si se trata de una asignacin como si se
trata de cualquiera de las operaciones que se pueden hacer sobre expresio-
nes, tienen que coincidir en tipo. Si no lo hacen, el compilador genera un
error en tiempo de compilacin.
Por ejemplo, si quisiramos sumar centmetros y segundos, aunque numricamente es

posible, ya que podemos expresar ambas magnitudes en trminos numricos, concep-
tualmente no tendra sentido. Si usamos un lenguaje fuertemente tipificado, el compila-
dor nos tiene que advertir de que estamos usando un tipo de datos incorrecto. En cambio,
si el lenguaje es de tipificacin dbil, el error se producir en tiempo de ejecucin.
Encapsulamiento
Consiste en agrupar todos los datos y operaciones relacionadas en una misma

clase. Esta propiedad facilita que aparezcan otras caractersticas de la progra-
macin orientada a objetos como la reutilizacin y la ocultacin de informa-
cin. De esta manera, y debido a la ocultacin de la informacin, los usuarios
de esta clase disponen de unos mtodos que permiten consultar y modificar
el comportamiento de esta clase, pero no tienen acceso directo a los datos.
Para aclarar los conceptos de encapsulamiento y ocultacin, podemos pensar en la clase

Date. Una fecha se puede descomponer en da, mes y ao, y puede tener unos mtodos
para acceder al da, al mes y al ao y otros para modificar la fecha que almacena.
Figura 4. Representacin de la clase Date
Cualquier objeto que intente consultar o establecer la fecha de este objeto, lo tendr que
hacer mediante las operaciones destinadas a esta finalidad y no podr acceder directa-
mente a los atributos que representan el da, el mes y el ao.
La ventaja de esta situacin es que si en cualquier momento tenemos que cam-

biar la representacin interna de los datos almacenados, no ser necesario mo-
dificar ninguna de las aplicaciones que utilizan objetos de tipo Date, ya que,
a pesar de cambiarse su estructura interna, no se modifica su comportamiento.
Otra de las ventajas del encapsulamiento es la posibilidad de ocultar ope-

raciones internas de la clase que no deben ser visibles por objetos externos
a sta. Por ejemplo, podramos tener un mtodo que, dada una fecha, com-
probase si sta es correcta y que slo sea accesible internamente.
Figura 5. Representacin de la clase Date

Esta operacin oculta puede servir para asegurarnos de que no insertamos

fechas errneas o para realizar cualquier otra operacin que se utiliza in-
ternamente pero que no se quiere que se ejecute desde otras partes del
programa.
Genericidad
Es la propiedad que permite definir mtodos que tienen como parmetros

elementos de cualquier tipo.
Un ejemplo de genericidad lo tendramos si quisiramos definir un objeto que fuera un

vector o una lista que pudiera recibir elementos de cualquier tipo. Esto tiene sentido por-
que el comportamiento de este objeto siempre es el mismo (aadir, borrar, insertar, etc.),
independientemente del tipo contenido. De esta manera, lo podramos usar una vez
como vector de enteros, otra como vector de caracteres, etc.
La genericidad es bsica para reutilizar cdigo.
Herencia
Propiedad que nos permite definir una clase segn otra u otras de manera
que la clase heredera tenga el mismo comportamiento y las caractersticas
que la clase de la cual hereda, ms las caractersticas y el comportamiento
que el programador le quiera aadir.
Por ejemplo, podramos definir una clase Persona con los atributos y mtodos corres-
pondientes y dos clases ms, Estudiante y Profesor, que hereden de la clase Persona.
Las tres clases tendran una parte comn, y las clases Estudiante y Profesor aadiran
otros mtodos y atributos especficos para cada una de stas.
Polimorfismo
El polimorfismo est estrechamente vinculado con la herencia. Se puede

definir como la propiedad por la cual se pueden realizar tareas diferentes
invocando la misma operacin, segn el tipo de objeto sobre el cual se in-
voca.
Continuamos con el ejemplo anterior de los Estudiantes y los Profesores. Si tuvi-

ramos un mtodo denominado getCreditos, en el caso de un estudiante, debera de-
volver el nmero de crditos de los que ste est matriculado, y en el caso de un profesor,
nos tendra que devolver el nmero de crditos de las asignaturas que imparte. Las tareas
necesarias para devolver el resultado segn el tipo de objeto seran diferentes.
stas son las caractersticas principales de los lenguajes de programacin

orientada a objetos, aunque hay lenguajes que incorporan otras caractersticas
propias adicionales, como la gestin de memoria (de C# y Java) o la gestin de
excepciones.
Resumen
En este mdulo, hemos ofrecido una visin genrica del contexto en el que
naci la orientacin a objetos y cmo se ha ido desarrollado hasta llegar a lo
que hoy conocemos como tal.
La orientacin a objetos surgi como una manera de construir simulaciones

en la dcada de los sesenta, cuando era complicado desarrollar y mantener los
sistemas de software. Bsicamente, con la programacin orientada a objetos,
se lleg a modelizar las entidades de una manera mucho ms prxima al mun-
do real, ya que los datos se organizan segn el tratamiento que reciben y no
como hasta entonces, que estaban organizados nicamente segn la descom-
posicin funcional que se realizaba de los mismos.
En la programacin orientada a objetos, cada mdulo bsico, tambin deno-

minado clase, representa los datos que definen una entidad del mundo real y
las operaciones necesarias para gestionar e interactuar con otras clases.
Esta manera nueva de desarrollar aplicaciones tiene muchas ventajas. Una de

las ms importantes es la reutilizacin del cdigo. Los sistemas anteriores de
reutilizacin de cdigo (recortar fragmentos de cdigo y pegarlos o agruparlos
en bibliotecas) se mejoran utilizando las clases, ya que stas contienen los da-
tos que representan la entidad e implementan todas las funcionalidades nece-
sarias en un mdulo nico que, una vez compilado, se puede utilizar en tantas
aplicaciones como sea necesario.
Hemos visto tambin que, inicialmente, los lenguajes de programacin que

haba no permitan aprovechar todo el potencial de la programacin orienta-
da a objetos, ya que no eran lenguajes especficos para este paradigma. Hemos
definido tambin las caractersticas bsicas que un lenguaje de programacin
orientada a objetos debe ofrecer:
Una tipificacin fuerte en tiempo de compilacin, para evitar errores en

tiempo de ejecucin causados por asignaciones incorrectas.
Encapsulamiento, para favorecer la ocultacin de informacin referente

tanto a la representacin interna de los datos como a la implementacin
de las funcionalidades ofrecidas.
La genericidad, que nos permite trabajar con clases que aceptan parme-
tros de diferentes tipos y nos permite ampliar, as, el rango de posibles uti-
lizaciones de nuestras clases.
La herencia, que nos permite propagar la estructura y el comportamiento

de una clase (la clase padre) a las clases que heredan de sta (las hijas), que
la especializan.
El polimorfismo, que posibilita que una misma operacin pueda realizar

tareas diferentes, dependiendo del tipo de objeto sobre el cual se ha invo-
cado.
Finalmente, hemos comentado que hoy da, vista la gran utilizacin de len-
guajes de programacin orientada a objetos, estn apareciendo lenguajes que
incorporan otras caractersticas que, aunque no son imprescindibles, son muy
tiles para el desarrollador.
Ejercicios de autoevaluacin
1. A partir de la lectura del ejemplo de profesores y departamentos del apartado 2.1, mencio-
nad algunas de las ventajas del paradigma de la orientacin a objetos respecto del enfoque
clsico.
2. Imaginad que se os pide ampliar el ejemplo anterior de manera que haya dos tipos dife-
rentes de profesores, los investigadores y los docentes. Los profesores investigadores estn
asignados a un grupo de investigacin y tienen una remuneracin fija, y los profesores do-
centes dan clase en diferentes asignaturas con un sueldo variable, dependiendo del nme-
ro de horas de clase que den. Todos los profesores tienen asignado un despacho de trabajo,
una direccin de correo electrnico y un centro.
a) Qu propiedad de los lenguajes de programacin orientada a objetos objeto tendra-
mos que utilizar para implementar las clases Profesor, Investigador y Docente?
b) Explicad en qu consiste esta propiedad.
c) Qu propiedad de los lenguajes de programacin orientada a objetos tendramos que
utilizar para implementar el mtodo de clculo de sueldos?
d) Explicad en qu consiste esta propiedad.
3. Proponed un ejemplo de una clase que se pueda reutilizar e indicad en qu contextos se

podra aplicar.
Solucionario
1. En el contexto concreto del ejemplo, utilizar el enfoque de orientacin a objetos simplifica
el diseo de la aplicacin y facilita su modificacin posterior.
Adems, la orientacin a objetos presenta ventajas como la posibilidad de reutilizar clases
ya implementadas o de repartir las tareas de implementacin entre miembros de un mis-
mo equipo con ms facilidad.
2.
a) La propiedad que se tiene que utilizar es la herencia, para tener una entidad denominada
Profesor con el despacho, el correo electrnico y el centro, y tambin los mtodos nece-
sarios para acceder a los datos internos de stos.
Aparte, tendramos otra entidad denominada Investigador, que relacionaramos con
el grupo de investigacin el enunciado no dice nada sobre los atributos y mtodos de
ste, y tambin anotaramos su sueldo.
Finalmente tendramos una entidad, Docente, que estara relacionada con las asignaturas
en las que imparte docencia (que deberan tener un atributo que indicara el nmero de
horas lectivas), un atributo que representara el precio de las horas lectivas.
b) La herencia nos permite definir una entidad nueva (clase) a partir de otra. La clase nue-
va tiene las mismas caractersticas que la clase a partir de la cual se define, y adems aporta
caractersticas que la hacen diferente.
La herencia potencia reutilizar el cdigo.
c) El polimorfismo es la propiedad que se debe utilizar para que dos entidades respondan
de manera diferente a la invocacin del mismo mtodo, el clculo del sueldo. En el caso
de los investigadores, se tiene que consultar el sueldo que tiene asignado, y en el caso de
los profesores docentes hay que saber el nmero de horas en las que imparte clases y se
tiene que multiplicar por el precio de las horas lectivas que tiene almacenado.
d) El polimorfismo nos permite separar la funcionalidad ofrecida del algoritmo necesario
para ofrecerla.
3. Hay muchos ejemplos de clases reutilizables, pero mencionaremos algunos de stos.

Vector: sirve para almacenar elementos y recuperarlos de manera eficiente.
Lista ordenada: sirve para almacenar elementos organizados segn un orden determi-
nado (creciente o decreciente).
Pilas: estructura de datos que nos permite recuperar los elementos en orden inverso al
de insercin.
Conjunto: representa el concepto de conjunto matemtico sobre el cual se pueden alma-
cenar elementos infinitos no repetidos y se pueden realizar operaciones como la intersec-
cin, unin, etc. de otros conjuntos.
Persona: como hemos visto durante todo el mdulo, ya que hemos estado trabajando so-
bre personas, tener una entidad Persona nos permite reutilizarla durante los ejemplos.
Glosario
encapsulamiento m Caracterstica de los mdulos que permite abstraer la gestin de la in-
formacin de stos de la representacin interna de la informacin que contienen.
genericidad f Caracterstica de un elemento de programacin que permite que se utilice

con tipos de datos diferentes.
herencia f Caracterstica de la programacin orientada a objetos por la cual una clase reuti-
liza la definicin de otra de la cual procede.
orientacin a objetos f Enfoque para desarrollar aplicaciones en las que el mundo real se
representa mediante mdulos de compilacin separada, denominados clases, que se relacio-
nan entre s.
polimorfismo m Caracterstica de los lenguajes de programacin orientada a objetos por

la cual una operacin se puede comportar de diferentes maneras segn el elemento sobre la
cual se invoca.
programacin procedimental f Enfoque del desarrollo de aplicaciones basado en la des-

composicin funcional de stas.
reutilizacin f Propiedad por la cual la misma pieza de software se puede utilizar distintas
veces en diferentes aplicaciones.
tipificacin de tipos de datos f Comprobacin de los tipos de datos de las expresiones.

Puede ser de dos tipos: tipificacin fuerte (realizada en tiempo de compilacin) o tipificacin
dbil (en tiempo de ejecucin).
Bibliografa
Booch, G. (1994). Object oriented analysis and design with applications. California: The
Benjamin Cummings Publishing Company.
Joyanes, L. (1998). Programacin orientada a objetos. Madrid: McGraw-Hill.
Meyer, B. (1999). Construccin de software orientado a objetos. Madrid: Prentice Hall.
Wikipedia <http://www.wikipedia.org>

Pid 00161674

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Pid 00161674

Загружено:

Авторское право:

Доступные форматы

Introduccin

1. Los inconvenientes de la programacin clsica ........................ 7

2. La orientacin a objetos .................................................................. 9

3. Lenguajes de programacin orientada a objetos ...................... 15

Ejercicios de autoevaluacin ............................................................... 23

En este mdulo, pretendemos proporcionar una visin genrica y global de la

1) Las dificultades que encontraban los programadores a la hora de hacer apli-

2) La gnesis de la orientacin a objetos y cmo, desde que naci, se orient

3) Finalmente, os presentamos la evolucin de los lenguajes de programacin de

Los materiales didcticos de este mdulo proporcionan los conocimientos

1. Conocer cmo naci el paradigma de la orientacin a objetos y qu proble-

2. Identificar la orientacin a objetos como una manera de resolver proble-

3. Conocer las ventajas principales de la orientacin a objetos, sobre todo con

4. Conocer las ventajas de disear y utilizar el cdigo reutilizable.

5. Conocer cmo han evolucionado los lenguajes de programacin de alto nivel.

6. Tener una visin general de conceptos relacionados estrechamente con la

1. Los inconvenientes de la programacin clsica

A finales de la dcada de los sesenta, concretamente en 1968, se reconoci p-

Si por s mismas las aplicaciones ya tratan de resolver problemas ciertamente

La complejidad del dominio y de la solucin hace que haya que descom-

Casi siempre que se construye una aplicacin, se identifican partes que se

Y para acabar, caracterizar el comportamiento de sistemas discretos es muy

Esta complejidad, unida a la falta de una metodologa a la hora de desarrollar

Reutilizacin difcil del cdigo, ya que los mdulos se caracterizaban por la

Mantenimiento difcil y costoso, ya que los mdulos estaban muy orienta-

Reduccin de la calidad de las aplicaciones, medida en flexibilidad, eficien-

La programacin orientada a objetos es una tcnica para construir aplicacio-

2.1. El nacimiento de una manera nueva de construir aplicaciones

Dalh y Nygaard trabajaban en un centro de clculo haciendo simuladores para

b) Con respecto a las modificaciones, vieron que el simulador se tena que

Cada pieza se tendra que implementar como un mdulo, que se denomin

Con esta nueva manera de implementar el simulador, se solucionaron los dos

Observad que, en este enfoque, los mdulos corresponden a entidades reales

Una vez expuesto cmo surgi la orientacin a objetos, podemos decir

La orientacin a objetos est basada en tres aspectos organizativos prximos

Un objeto y sus caractersticas; por ejemplo, un coche tiene un color, un

Antes de empezar a implementar cualquier problema, es necesario examinar

A continuacin, mostraremos un ejemplo que nos permitir comprobar las

De las asignaturas, habr que saber el nombre y las horas de docencia.

Solucin con el desarrollo clsico

Solucin con el desarrollo orientado a objetos

A la vista del ejemplo anterior, podramos decir que la orientacin a ob-

Algunos argumentos para usar la programacin orientada a objetos son la me-

2.2. Reutilizacin del cdigo

Gracias a la programacin orientada a objetos, dado que cada pieza se

Esta propiedad de poder utilizar elementos de software programados y probados

reutilizacin o reusabilidad. ... se supone que hay un repo-

digo en las siguientes:

Disminucin de los esfuerzos de mantenimiento. Puesto que todo el cdi-

Ms velocidad en el desarrollo, favorecida principalmente por el hecho de

Aumento de la fiabilidad de los programas. Ya que es un mdulo progra-

se puede crear una representacin mejor que si no se tienen estos conoci-

Ms eficiencia, principalmente por las mismas razones que en el caso ante-

Aumento de la consistencia de la aplicacin para usar componentes ms

Abaratamiento de costes favorecido por el hecho de no tener que realizar

... nos permiten seleccionar di-

a) Eficiencia de nuestra aplicacin para tratar la interfaz grfica, ya que supo-

b) Fiabilidad de la interfaz grfica, ya que estos elementos estn muy proba-

c) Consistencia de la interfaz de usuario, dado que todos los elementos tienen

d) Ms velocidad de desarrollo y menos costes. Como hemos comentado, estos

e) Eliminacin de los costes de mantenimiento, ya que estos elementos, pues-

estado (pulsado / no pulsado, activo / inactivo, etc.) y un comportamiento

3. Lenguajes de programacin orientada a objetos