Introducción

a la orientación
a objetos
Jordi Brínquez Jiménez
Elena García Barriocanal

PID_00161674
© FUOC • PID_00161674 Introducción a la orientación a objetos

Índice

Introducción ............................................................................................ 5

Objetivos ................................................................................................... 6

1. Los inconvenientes de la programación clásica ........................ 7

2. La orientación a objetos .................................................................. 9

2.1. El nacimiento de una manera nueva
de construir aplicaciones ................................................................ 9
2.2. Reutilización del código ................................................................. 12

3. Lenguajes de programación orientada a objetos ...................... 15

3.1. Evolución histórica de los lenguajes de programación .................. 15
3.2. Evolución de los lenguajes de programación orientada
a objetos .......................................................................................... 17
3.3. Características básicas de los lenguajes de programación
orientada a objetos ......................................................................... 18

Resumen .................................................................................................... 21

Ejercicios de autoevaluación ............................................................... 23

Solucionario ............................................................................................. 24

Glosario ..................................................................................................... 24

Bibliografía .............................................................................................. 25
© FUOC • PID_00161674 5 Introducción a la orientación a objetos

Introducción

En este módulo, pretendemos proporcionar una visión genérica y global de la

orientación a objetos que permita a los estudiantes empezar a familiarizarse
con los conceptos en los que profundizaremos durante la asignatura.

El presente módulo 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 años 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 construcción.

2) La génesis de la orientación a objetos y cómo, desde que nació, se orientó

a resolver los problemas que había en el ámbito de la simulación. Después,
poco a poco, se extendió su uso a otros campos de aplicación hasta llegar a los
años 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 evolución de los lenguajes de programación de

alto nivel. En esta evolución, podemos ver que los lenguajes se ocupaban cada vez
más de conceptos relacionados con la modularización y la abstracción. También
vemos que, con la orientación a objetos, es necesario introducir conceptos nuevos
en los lenguajes de programación para que éstos soporten toda la potencia de este
paradigma. Para acabar, os mostramos cuáles son las características que deben te-
ner los lenguajes de programación orientada a objetos.
© FUOC • PID_00161674 6 Introducción a la orientación a objetos

Objetivos

Los materiales didácticos de este módulo proporcionan los conocimientos

fundamentales para que los estudiantes alcancéis los objetivos siguientes:

1. Conocer cómo nació el paradigma de la orientación a objetos y qué proble-

mas intenta resolver.

2. Identificar la orientación a objetos como una manera de resolver proble-

mas más próxima al razonamiento humano y que refleja mejor el dominio
de la aplicación que la programación procedimental.

3. Conocer las ventajas principales de la orientación a objetos, sobre todo con

respecto a la reutilización del código.

4. Conocer las ventajas de diseñar y utilizar el código reutilizable.

5. Conocer cómo han evolucionado los lenguajes de programación de alto nivel.

6. Tener una visión general de conceptos relacionados estrechamente con la

orientación a objetos, como el encapsulamiento, la herencia, la generici-
dad o el polimorfismo.
© FUOC • PID_00161674 7 Introducción a la orientación a objetos

1. Los inconvenientes de la programación clásica

A finales de la década de los sesenta, concretamente en 1968, se reconoció pú-

blicamente en una conferencia organizada por la Comisión Científica de la
OTAN que había un problema en el desarrollo de los sistemas de software que
hacía que no fueran tan útiles como se esperaba. Concretamente, las aplica-
ciones que se construían, o bien no llegaban nunca a completarse con éxito,
o bien, además de ser muy costosas, su volumen y falta de estructuración las
hacía prácticamente imposibles de mantener y, por otra parte, escasamente
fiables. Esta situación fue denominada con la expresión crisis del software.
Lectura recomendada
Las causas que dieron lugar a esta situación tienen el origen en la comple-
F. P. Brooks (1987, abril).
jidad intrínseca 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 análisis
complejos, el equipo de desarrollo no suele tener claro desde el primer de requerimientos...
momento qué se espera de la aplicación, 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 reducirían.

• La complejidad del dominio y de la solución hace que haya que descom-

poner la aplicación en gran cantidad de módulos 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 diseño de la aplicación.

• Casi siempre que se construye una aplicación, se identifican partes que se

podrían resolver de manera parecida a como se hizo en aplicaciones an-
teriores, pero la ausencia casi absoluta de estándares en la industria del
software hace que aquello que ya se ha implementado sea difícilmente
reutilizable.

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

difícil. Estos sistemas pueden tener un número 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.
© FUOC • PID_00161674 8 Introducción a la orientación a objetos

Esta complejidad, unida a la falta de una metodología a la hora de desarrollar

En el desarrollo
las aplicaciones, hacía que los desarrollos basados en las estructuras de datos estructurado clásico...
clásicos presentaran los inconvenientes siguientes: ... se conciben las aplicaciones
como una función 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 más
todo utilizado para construir las aplicaciones está basado en el hecho de específicas.
descomponer la aplicación en una jerarquía de módulos funcionales idea-
dos para transformar unas entradas determinadas en salidas bien definidas.
Este tipo de diseños no facilitan resolver problemas complejos desestructu-
rados. Se trata de un enfoque más apropiado para resolver problemas es-
tructurados, en los que se puede describir el código según algoritmos de
transformación de datos.

• Reutilización difícil del código, ya que los módulos se caracterizaban por la

transformación concreta de datos, cosa que lo hacía muy dependiente de
la aplicación original.

• Mantenimiento difícil y costoso, ya que los módulos estaban muy orienta-

dos a tratar los datos y normalmente, durante su desarrollo, no se tenían
en cuenta posibles cambios futuros.

• Reducción de la calidad de las aplicaciones, medida en flexibilidad, eficien-

cia, fiabilidad y robustez, criterios que trataremos en el módulo siguiente.
La calidad se reduce a medida que se hacen modificaciones, ya que éstas
complican cada vez más el diseño original, con lo cual se resta flexibilidad
al desarrollo y cada vez resulta más complejo introducir nuevos cambios.
© FUOC • PID_00161674 9 Introducción a la orientación a objetos

2. La orientación a objetos

La programación orientada a objetos es una técnica para construir aplicacio-

nes más antigua de lo que puede parecer. Si bien pasó desapercibida hasta
principios de la década de los noventa, su origen se remonta a 1967, cuando
dos noruegos, Ole-Johan Dahl y Kristen Nygaard, idearon los conceptos bási-
cos de la programación 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 cálculo haciendo simuladores para

procesos industriales y científicos. A la hora de llevar a cabo las simulaciones,
encontraron dos tipos de problemas fundamentales, además de las dificulta-
des que cualquier desarrollo ya implicaba:

a) En cuanto al diseño del simulador, vieron que no sólo era necesario tener
conocimientos de informática para poder implementarlo, sino que además se
necesitaba tener conocimientos amplios de ingeniería para identificar y espe-
cificar adecuadamente las características y el comportamiento del sistema real.

b) Con respecto a las modificaciones, vieron que el simulador se tenía 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 módulo “Clases y objetos”,
se definirán 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
módulo.
objetivo de que reflejaran los sistemas reales de la manera más fiel posible. En
vez de construir aplicaciones monolíticas, los módulos simularían cada una de
las piezas necesarias, y éstas se comunicarían entre sí como lo hacen en el
mundo real.

Cada pieza se tendría que implementar como un módulo, que se denominó

clase, y que tendría los valores necesarios para representar su estado, sus atributos
y un conjunto de rutinas que servirían para gestionar todas las señales que esta
pieza podría recibir de los otros módulos, sus métodos. Además, tendría la capa-
cidad de comunicarse con los otros módulos con los que estuviera relacionada,
ya que almacenaría información sobre éstos para poder enviarles señales.

A partir de lo que hemos explicado hasta ahora, podemos dar una primera de-
finición informal de objeto:

Un objeto es una representación 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.
© FUOC • PID_00161674 10 Introducción a la orientación a objetos

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

problemas principales que hemos comentado anteriormente.

Por una parte, los informáticos ya no tenían que conocer a fondo el campo de
la ingeniería, sino que un ingeniero o físico, por ejemplo, les proporcionaría
la descripción exacta del funcionamiento de cada pieza y ellos sólo tendrían
que implementar el comportamiento de la pieza de acuerdo con la especifica-
ción dada.

Por otra parte, las modificaciones resultaban mucho más sencillas porque aho-
ra ya no había que perder demasiado tiempo para localizar las partes afectadas
por los cambios, únicamente era necesario identificar la pieza en la que se te-
nían que realizar los ajustes y modificar su módulo.

Observad que, en este enfoque, los módulos corresponden a entidades reales

–que en el caso del simulador son las “piezas” del sistema–, no como hasta
ahora, que el concepto de módulo se limitaba a agrupar ciertas funcionalida-
des del proceso al que eran sometidos los datos (captura de datos, cálculos, ac-
tualizaciones, etc.).

Una vez expuesto cómo surgió la orientación a objetos, podemos decir

que se trata de una manera nueva de resolver problemas más ajustada
al mundo real y, por lo tanto, más próxima al proceso mental de las
personas.

La orientación a objetos está basada en tres aspectos organizativos próximos

al razonamiento humano, ya que establecen conexiones entre los elementos
siguientes:

– Un objeto y sus características; por ejemplo, un coche tiene un color, un

número 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 características 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 camión ni un avión.

Teniendo en cuenta todo lo que hemos explicado hasta ahora, podemos decir
que la orientación a objetos va más allá de la implementación de aplicaciones.
La orientación a objetos define toda una filosofía para analizar y diseñar estas
aplicaciones.

Antes de empezar a implementar cualquier problema, es necesario examinar

qué requisitos hay desde la perspectiva de la programación orientada a objetos
© FUOC • PID_00161674 11 Introducción a la orientación 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 programación que se utilizará, dado que no todos los lenguajes
implementan los conceptos de la programación orientada a objetos de la mis-
ma manera.

A continuación, 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 aplicación para gestionar las nóminas de los profesores de una
facultad y la dotación económica 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.

Según la carga docente, los departamentos tienen una dotación económica u otra.

Para nuestra aplicación, necesitaremos saber los datos que modelan los departamentos
(nombre, director, secretario, dirección postal, los profesores que hay asignados, etc.) y
una operación que nos diga cuál es la dotación económica de los departamentos (para
evaluarla, necesitaremos saber el número 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 electrónico, 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.

Solución con el desarrollo clásico

Por una parte, tendríamos que definir las estructuras de datos que necesitaríamos en
nuestra aplicación (departamento, profesor y asignatura) y, para cada una de éstas, debe-
ríamos definir una estructura de datos para almacenarlas todas.

Después necesitaríamos una estructura de datos que nos permitiera representar las rela-
ciones entre los departamentos y los profesores, y otra para representar la relación entre
los profesores y las asignaturas.

Finalmente, tendríamos que implementar las operaciones que nos permitieran realizar
las funcionalidades pedidas, y también otras operaciones que nos sirviesen para “nave-
gar” entre las relaciones almacenadas.

Solución con el desarrollo orientado a objetos

En este caso, lo que tendríamos que hacer es identificar cada entidad (departamento, pro-
fesor y asignatura) y utilizar tres módulos diferentes en los que se definirían las propie-
dades de cada entidad y se implementarían las funcionalidades por separado.

Por ejemplo, en la operación del departamento de cálculo de las horas lectivas (para cal-
cular la asignación), 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, sólo haría falta pedirles las horas lectivas y sumarlas.

Una vez definidas estas entidades en nuestra aplicación de gestión, tendríamos 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 sería necesaria una estructura que representara las relaciones, ya que los
objetos ya están relacionados entre sí.
© FUOC • PID_00161674 12 Introducción a la orientación a objetos

A la vista del ejemplo anterior, podríamos decir que la orientación 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 más rápido y hacer modificaciones es más sencillo.

Algunos argumentos para usar la programación orientada a objetos son la me-

jora de la calidad de las aplicaciones, la escalabilidad y adaptabilidad de éstas,
y también la disminución del tiempo y el coste de desarrollo. Gran parte de
estas ventajas provienen de otra fundamental: el concepto de reutilización del
código, que veremos en el apartado siguiente.

2.2. Reutilización del código

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 técnicas
que se utilizaban en la programación clásica, el único mecanismo de reutiliza-
ción posible era crear bibliotecas de funcionalidades que se podían invocar
desde diferentes simulaciones (programas).

Gracias a la programación orientada a objetos, dado que cada pieza se

implementa como un elemento completo –tiene unas propiedades y
métodos propios de manera autocontenida– y separado del resto, cual-
quier pieza se puede utilizar en diseños nuevos sin ninguna, o escasa,
modificación.

Esta propiedad de poder utilizar elementos de software programados y probados

En el concepto de
previamente durante la construcción de aplicaciones nuevas se denomina reutilización de código...

reutilización o reusabilidad. ... se supone que hay un repo-

sitorio de donde se pueden
tomar los módulos ya imple-
Podemos resumir las ventajas principales que se obtienen de reutilizar un có- mentados.

digo en las siguientes:

• Disminución de los esfuerzos de mantenimiento. Puesto que todo el códi-

go que afecta a una entidad está en un mismo módulo, las tareas de man-
tenimiento se basan en modificaciones de aquel módulo.

• Más 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 módulo progra-

mado por una persona con conocimientos sobre la entidad que representa,
© FUOC • PID_00161674 13 Introducción a la orientación a objetos

se puede crear una representación mejor que si no se tienen estos conoci-

mientos.

• Más 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 aplicación para usar componentes más

fiables y eficientes.

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

tareas básicas en cada proyecto, ya que se pueden aprovechar de proyectos
anteriores.

Para ejemplarizar mejor el concepto de reutilización de código, podemos Las listas desplegables...
hablar de las interfaces gráficas de usuario. Esta colección de elementos
... nos permiten seleccionar
que utilizamos cuando desarrollamos aplicaciones gráficas (menús, botones, una opción 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
programación nos ofrecen. Si los tuviéramos que implementar nosotros,
aparte de que deberíamos tener un gran conocimiento sobre este tema,
necesitaríamos mucho más tiempo, ya que estos elementos los utilizamos
muchas veces en nuestro programa.
Los menús...

... nos permiten seleccionar di-

El desarrollo de los elementos de las interfaces gráficas 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 programación orientada a objetos:

a) Eficiencia de nuestra aplicación para tratar la interfaz gráfica, ya que supo-

nemos que estos elementos son lo más eficientes posible.

b) Fiabilidad de la interfaz gráfica, ya que estos elementos están muy proba-

dos y, por lo tanto, no presentarán un comportamiento inesperado.

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

unas características parecidas.

d) Más velocidad de desarrollo y menos costes. Como hemos comentado, estos

elementos ya nos vienen dados y, por lo tanto, ahorramos tiempo y dinero.

e) Eliminación de los costes de mantenimiento, ya que estos elementos, pues-

to que ya están 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 botón, el texto de los menús, etc.), un
© FUOC • PID_00161674 14 Introducción a la orientación a objetos

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

(permiten la escritura de texto o de contraseñas, la ordenación de tablas, etc.).
Estas propiedades de la biblioteca gráfica ya están implementadas y están dis-
ponibles para utilizarlas.
© FUOC • PID_00161674 15 Introducción a la orientación a objetos

3. Lenguajes de programación orientada a objetos

3.1. Evolución histórica de los lenguajes de programación

Los lenguajes de programación han tenido grandes transformaciones durante

Las grandes
su historia. Hay muchas clasificaciones que, según diferentes criterios, así lo transformaciones
muestran. Una de las más conocidas es la clasificación de Wegner, que divide La ampliación del campo de
aplicación de los programas, el
los lenguajes de programación de alto nivel de acuerdo con el orden de
abaratamiento de los ordena-
aparición y las características comunes. Concretamente, la clasificación consta dores y de su potencia cada
vez más elevada.
de lenguajes de primera generación, de segunda generación, de tercera
generación y la generación de los lenguajes actuales.

a) Lenguajes de primera generación

Lenguajes que se desarrollaron entre 1954 y 1958. Con éstos se produjo un sal-
to en la abstracción a la hora de programar, ya que anteriormente se utilizaba
el lenguaje ensamblador, que requería un buen conocimiento de la máquina
en la que se ejecutaría el código. Algunos ejemplos de estos lenguajes son For-
tran I, Algol 58 o IPL V: todos estaban basados en expresiones matemáticas y,
por lo tanto, su dominio de aplicación estaba centrado en el cálculo y las apli-
caciones científicas y de ingeniería.

Los programas que se hacían con estos lenguajes se basaban en subprogramas

que compartían los datos al ser ejecutados.

Figura 1. Lenguajes de primera generación

Esta situación presentaba problemas serios porque cualquier error en el fun-

cionamiento de un subprograma se propagaba al resto de la aplicación. Apar-
te, cuando el programa era demasiado grande, cualquier cambio se traducía en
una tarea muy costosa que no siempre se conseguía llevar a cabo sin complicar
todavía más el diseño original.
© FUOC • PID_00161674 16 Introducción a la orientación a objetos

b) Lenguajes de segunda generación

Aparecieron a finales de la década de los cincuenta y a principios de los sesen-

ta. En estos lenguajes, se empezó a poner énfasis en la abstracción algorítmica
y la programación se extendió poco a poco a otros dominios del mundo real.
Algunos de los lenguajes pertenecientes a esta generación son Cobol, Algol 60
o Fortran II.

En el terreno de la estructuración de los programas, la segunda generación em-

pieza a introducir el concepto de procedimientos dentro de los subprogramas,
con lo cual aparecen los conceptos de paso de parámetros y de visibilidad de
las variables.

Figura 2. Lenguajes de segunda generación

c) Lenguajes de tercera generación

Comprende los lenguajes creados entre 1962 y 1970. En esta época, los costes
del hardware continúan abaratándose, lo cual hace que las aplicaciones infor-
máticas lleguen cada vez más a ámbitos más distintos. Esta diversificación en los
campos de trabajo comporta que se tenga que trabajar con tipos de datos dife-
rentes de los puramente matemáticos, y cambiantes de una aplicación 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 generación

© FUOC • PID_00161674 17 Introducción a la orientación a objetos

Este nuevo concepto resuelve algunos problemas de la programación de

aplicaciones grandes, ya que de esta manera distintos desarrolladores pue-
den implementar módulos diferentes que se pueden compilar por separado
y, finalmente, combinarlos. A pesar de todo, durante esta época el concep-
to de abstracción de los datos no fue demasiado utilizado como tal, sino
que simplemente permitía agrupar distintas funcionalidades en módulos
diferentes.

Otro concepto que no existía era el de la visibilidad de los datos. Por lo tanto,
nada impedía que diferentes módulos modificasen directamente los datos de
otros módulos (en línea discontinua en el diagrama anterior).

d) Lenguajes de cuarta generación o actuales

Estos son lenguajes de programación que no son de propósito general, como

los descritos anteriormente. Han sido diseñados para algún propósito especí-
fico. Entre otros, están Sculptor, Dbase, SAS y PHP.

3.2. Evolución de los lenguajes de programación

orientada a objetos

El primer lenguaje orientado a objetos fue SIMULA 67. Fue creado por cientí-
ficos noruegos (Nygaard y Gahl) que, después de probar otros lenguajes de ter-
cera generación, decidieron crear un lenguaje que les permitiera realizar todo
lo que los otros no les permitían a causa de las limitaciones que tenían.

SIMULA 67 fue el primer lenguaje de programación en el que se introdujeron

los conceptos de clase y objeto.

Más tarde, a principios de los años 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 gráfica de usuario. Enseguida los desarrolladores relacionaron las
ideas de la programación orientada a objetos con las piezas del ordenador nue-
vo, ya que se podía definir perfectamente el funcionamiento de cada elemento
gráfico como un objeto, porque tenía un comportamiento muy definido y res-
pondía a interacciones muy concretas.

Para implementar el proyecto DynaBook, elaboraron un lenguaje de programa-

ción nuevo denominado Smalltalk, que estaba fuertemente influido por SIMU-
LA 67. Este lenguaje introducía el concepto de herencia de manera explícita.

La herencia es el mecanismo que permite que un objeto comparta las caracte-

rísticas y el comportamiento de otro objeto, del cual se dice que hereda.
© FUOC • PID_00161674 18 Introducción a la orientación a objetos

El concepto de herencia es muy valioso para reutilizar código, ya que deter-

minados objetos, aunque no son idénticos, sí que tienen características comu-
nes. Por ejemplo, toda persona tiene un nombre y una fecha de nacimiento.
Estas propiedades se utilizarán tanto si dentro de nuestra aplicación la persona
es una estudiante como si es un profesor. En próximos módulos, lo estudiare-
mos más detalladamente.

A partir de este momento, los lenguajes de programación orientada a objetos

van incorporando características nuevas que los hacen evolucionar hasta los
lenguajes de programación que conocemos hoy en día.

En la década de los ochenta, Bjarne Stroustrup, empleado de AT&T Labs., am-

plió el lenguaje de programación C para adaptarlo a la programación 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-
tación 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 programación orientada a objetos en ver-
siones sucesivas, como las clases abstractas, los métodos static o la genericidad.
Veremos todos estos conceptos en los próximos módulos.

Actualmente hay muchos lenguajes de programación orientada a objetos, unos

descendientes de lenguajes procedimentales que se han adaptado al paradigma
de la programación 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. Características básicas de los lenguajes de programación

orientada a objetos

La mayoría de los lenguajes de programación orientada a objetos cumplen una

serie de características que nos permiten utilizar todo el potencial de la orien-
tación a objetos:

• Tipificación estricta

Éste es un concepto que, aunque no es específico de la programación orien-

tada a objetos, es necesario cumplir. Este hecho implica que si dos expre-
siones están relacionadas, tanto si se trata de una asignación 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 compilación.
© FUOC • PID_00161674 19 Introducción a la orientación a objetos

Por ejemplo, si quisiéramos sumar centímetros y segundos, aunque numéricamente es

posible, ya que podemos expresar ambas magnitudes en términos numéricos, concep-
tualmente no tendría 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 tipificación débil, el error se producirá en tiempo de ejecución.

• Encapsulamiento

Consiste en agrupar todos los datos y operaciones relacionadas en una misma

clase. Esta propiedad facilita que aparezcan otras características de la progra-
mación orientada a objetos como la reutilización y la ocultación de informa-
ción. De esta manera, y debido a la ocultación de la información, los usuarios
de esta clase disponen de unos métodos 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 ocultación, podemos pensar en la clase

Date. Una fecha se puede descomponer en día, mes y año, y puede tener unos métodos
para acceder al día, al mes y al año y otros para modificar la fecha que almacena.

Figura 4. Representación 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 día, el mes y el año.

La ventaja de esta situación es que si en cualquier momento tenemos que cam-

biar la representación 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, podríamos tener un método que, dada una fecha, com-
probase si ésta es correcta y que sólo sea accesible internamente.

Figura 5. Representación de la clase Date

© FUOC • PID_00161674 20 Introducción a la orientación a objetos

Esta operación oculta puede servir para asegurarnos de que no insertamos

fechas erróneas o para realizar cualquier otra operación 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 métodos que tienen como parámetros

elementos de cualquier tipo.

Un ejemplo de genericidad lo tendríamos si quisiéramos 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 (añadir, borrar, insertar, etc.),
independientemente del tipo contenido. De esta manera, lo podríamos usar una vez
como vector de enteros, otra como vector de caracteres, etc.

La genericidad es básica para reutilizar código.

• Herencia

Propiedad que nos permite definir una clase según otra u otras de manera
que la clase heredera tenga el mismo comportamiento y las características
que la clase de la cual hereda, más las características y el comportamiento
que el programador le quiera añadir.

Por ejemplo, podríamos definir una clase Persona con los atributos y métodos corres-
pondientes y dos clases más, Estudiante y Profesor, que hereden de la clase Persona.
Las tres clases tendrían una parte común, y las clases Estudiante y Profesor añadirían
otros métodos y atributos específicos 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 operación, según 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 método denominado getCreditos, en el caso de un estudiante, debería de-
volver el número de créditos de los que éste está matriculado, y en el caso de un profesor,
nos tendría que devolver el número de créditos de las asignaturas que imparte. Las tareas
necesarias para devolver el resultado según el tipo de objeto serían diferentes.

Éstas son las características principales de los lenguajes de programación

orientada a objetos, aunque hay lenguajes que incorporan otras características
propias adicionales, como la gestión de memoria (de C# y Java) o la gestión de
excepciones.
© FUOC • PID_00161674 21 Introducción a la orientación a objetos

Resumen

En este módulo, hemos ofrecido una visión genérica del contexto en el que
nació la orientación a objetos y cómo se ha ido desarrollado hasta llegar a lo
que hoy conocemos como tal.

La orientación a objetos surgió como una manera de construir simulaciones

en la década de los sesenta, cuando era complicado desarrollar y mantener los
sistemas de software. Básicamente, con la programación orientada a objetos,
se llegó a modelizar las entidades de una manera mucho más próxima al mun-
do real, ya que los datos se organizan según el tratamiento que reciben y no
como hasta entonces, que estaban organizados únicamente según la descom-
posición funcional que se realizaba de los mismos.

En la programación orientada a objetos, cada módulo básico, también 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 más importantes es la reutilización del código. Los sistemas anteriores de
reutilización de código (recortar fragmentos de código 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 módulo único que, una vez compilado, se puede utilizar en tantas
aplicaciones como sea necesario.

Hemos visto también que, inicialmente, los lenguajes de programación que

había no permitían aprovechar todo el potencial de la programación orienta-
da a objetos, ya que no eran lenguajes específicos para este paradigma. Hemos
definido también las características básicas que un lenguaje de programación
orientada a objetos debe ofrecer:

• Una tipificación fuerte en tiempo de compilación, para evitar errores en

tiempo de ejecución causados por asignaciones incorrectas.

• Encapsulamiento, para favorecer la ocultación de información referente

tanto a la representación interna de los datos como a la implementación
de las funcionalidades ofrecidas.

• La genericidad, que nos permite trabajar con clases que aceptan paráme-
tros de diferentes tipos y nos permite ampliar, así, el rango de posibles uti-
lizaciones de nuestras clases.
© FUOC • PID_00161674 22 Introducción a la orientación a objetos

• 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 operación pueda realizar

tareas diferentes, dependiendo del tipo de objeto sobre el cual se ha invo-
cado.

Finalmente, hemos comentado que hoy día, vista la gran utilización de len-
guajes de programación orientada a objetos, están apareciendo lenguajes que
incorporan otras características que, aunque no son imprescindibles, son muy
útiles para el desarrollador.
© FUOC • PID_00161674 23 Introducción a la orientación a objetos

Ejercicios de autoevaluación
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 orientación a objetos respecto del enfoque
clásico.

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 están
asignados a un grupo de investigación y tienen una remuneración fija, y los profesores do-
centes dan clase en diferentes asignaturas con un sueldo variable, dependiendo del núme-
ro de horas de clase que den. Todos los profesores tienen asignado un despacho de trabajo,
una dirección de correo electrónico y un centro.
a) ¿Qué propiedad de los lenguajes de programación orientada a objetos objeto tendría-
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 programación orientada a objetos tendríamos que
utilizar para implementar el método de cálculo 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
podría aplicar.
© FUOC • PID_00161674 24 Introducción a la orientación a objetos

Solucionario
1. En el contexto concreto del ejemplo, utilizar el enfoque de orientación a objetos simplifica
el diseño de la aplicación y facilita su modificación posterior.
Además, la orientación a objetos presenta ventajas como la posibilidad de reutilizar clases
ya implementadas o de repartir las tareas de implementación entre miembros de un mis-
mo equipo con más facilidad.

2.
a) La propiedad que se tiene que utilizar es la herencia, para tener una entidad denominada
Profesor con el despacho, el correo electrónico y el centro, y también los métodos nece-
sarios para acceder a los datos internos de éstos.
Aparte, tendríamos otra entidad denominada Investigador, que relacionaríamos con
el grupo de investigación –el enunciado no dice nada sobre los atributos y métodos de
éste–, y también anotaríamos su sueldo.
Finalmente tendríamos una entidad, Docente, que estaría relacionada con las asignaturas
en las que imparte docencia (que deberían tener un atributo que indicara el número de
horas lectivas), un atributo que representaría 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 características que la clase a partir de la cual se define, y además aporta
características que la hacen diferente.
La herencia potencia reutilizar el código.
c) El polimorfismo es la propiedad que se debe utilizar para que dos entidades respondan
de manera diferente a la invocación del mismo método, el cálculo 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 número 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 según un orden determi-
nado (creciente o decreciente).
• Pilas: estructura de datos que nos permite recuperar los elementos en orden inverso al
de inserción.
• Conjunto: representa el concepto de conjunto matemático sobre el cual se pueden alma-
cenar elementos infinitos no repetidos y se pueden realizar operaciones como la intersec-
ción, unión, etc. de otros conjuntos.
• Persona: como hemos visto durante todo el módulo, ya que hemos estado trabajando so-
bre personas, tener una entidad Persona nos permite reutilizarla durante los ejemplos.

Glosario
encapsulamiento m Característica de los módulos que permite abstraer la gestión de la in-
formación de éstos de la representación interna de la información que contienen.

genericidad f Característica de un elemento de programación que permite que se utilice

con tipos de datos diferentes.

herencia f Característica de la programación orientada a objetos por la cual una clase reuti-
liza la definición de otra de la cual procede.

orientación a objetos f Enfoque para desarrollar aplicaciones en las que el mundo real se
representa mediante módulos de compilación separada, denominados clases, que se relacio-
nan entre sí.

polimorfismo m Característica de los lenguajes de programación orientada a objetos por

la cual una operación se puede comportar de diferentes maneras según el elemento sobre la
cual se invoca.

programación procedimental f Enfoque del desarrollo de aplicaciones basado en la des-

composición funcional de éstas.

reutilización f Propiedad por la cual la misma pieza de software se puede utilizar distintas
veces en diferentes aplicaciones.

tipificación de tipos de datos f Comprobación de los tipos de datos de las expresiones.

Puede ser de dos tipos: tipificación fuerte (realizada en tiempo de compilación) o tipificación
débil (en tiempo de ejecución).
© FUOC • PID_00161674 25 Introducción a la orientación a objetos

Bibliografía
Booch, G. (1994). Object oriented analysis and design with applications. California: The
Benjamin Cummings Publishing Company.

Joyanes, L. (1998). Programación orientada a objetos. Madrid: McGraw-Hill.

Meyer, B. (1999). Construcción de software orientado a objetos. Madrid: Prentice Hall.

Wikipedia <[Link]