PDF de programación - Programación Orientada a Objetos

Programación Orientada a Objetos

Laura M. Castro Souto

Primer Cuatrimestre

Curso 2000/2001

2

Índice de cuadros

4.1. Tabla resumen de la evolución de la Orientación a Objetos . . . . . . . . . 34

3

4

ÍNDICE DE CUADROS

Capítulo 1

Evolución de los lenguajes de
programación

La programación ha ido evolucionando desde sus orígenes, donde los lenguajes eran
de muy bajo nivel y las posibilidades reducidas, refinándose cada vez más hasta alcanzar
el alto nivel y relativa sencillez actuales.

Veremos a grandes rasgos cómo se ha desarrollado este proceso.

1.1. Programación no estructurada

En sus primeros momentos, decimos que la programación llevada a cabo en lenguajes
como el basic es no estructurada. Los programas eran una serie de líneas de código con
saltos (instrucciónes tipo goto) y en un único bloque (sin posibilidad de subrutinas;
basic cuenta únicamente con la instrucción gosub <dirección>).

1.2. Programación procedimental

Con la aparición de lenguajes como Pascal, surge la posibilidad del empleo de subruti-
nas (funciones y procedimientos), lo que da nombre a esta “etapa” en que la programación
se dice procedimental.

1.3. Programación estructurada

La necesidad de dar claridad y legibilidad al código provoca que se reconozcan una serie
de principios o reglas a la hora de estructurar un programa. Surge así la programación
estructurada, cuyas directivas son:

Estructura jerárquica top-down.

Diseño modular.

Salidas y entradas claramente definidas.

Único punto de entrada y único punto de salida (también aplicable a funciones).

Constructores de programación estructurada: secuencia, selección, iteración y lla-
madas a procedimientos.

5

6

CAPÍTULO 1. EVOLUCI ÓN DE LOS LENGUAJES DE PROGRAMACI ÓN

Existe una analogía entre este modo programación, esta forma de programar, propug-
nada por la programación estructurada y el llamado diseño mediante refinamiento
progresivo. Se afronta el problema desde la “cima” y se va analizando de forma que
se delimitan sucesiva y claramente las partes y funciones que realizarán cada una de las
cuales, hasta llegar a las más sencillas, directamente implementables de una manera fácil.

1.4. Programación modular

El siguiente paso consistió en la división de los largos programas, compuestos de líneas
y líneas de código en secuencia sin interrupción en diferentes módulos, en los que, por
ejemplo, podían trabajar simultáneamente los diferentes integrantes de un grupo ó depar-
tamento.

Los módulos, sin embargo, no permiten la instanciación ni la exportación de tipos.
Este iba a ser el siguiente peldaño en la escalera de la evolución de los lenguajes de
programación.

1.5. TADs

Los Tipos Abstractos de Datos cuentan con una serie de características que exponemos

a continuación:

◦ Exportan una definición de tipo.
◦ Hacen disponibles operaciones para manipular instancias del tipo (interfaz ).
◦ El interfaz es el único mecanismo de acceso a la estructura del TAD.
◦ Es posible crear múltiples instancias del tipo (algo que no era posible en programa-

ción modular).

El segundo y tercer puntos son comunes a los módulos. Son los otros dos los que

marcan la diferencia.

La filosofía consiste en que creamos nuevos tipos y los usamos como si fuesen predefi-

nidos. Es el paso previo a la orientación a objetos.

1.6. Programación Orientada a Objetos

1

Clases y objetos serán para nosotros conceptos similares a tipos y variables. Es decir,
la relación que existe entre un objeto y la clase a la que pertenece (la clase de la que es
una instancia 2.) es análoga a la que hay entre una variable y el tipo del que es declarada.

Una clase es un TAD con una característica añadida: permite la herencia.

clase = TAD + herencia

1simula 67 es el primer lenguaje que se puede considerar que soporta P.O.O.
2Realmente la palabra instancia no existe en español; debería usarse ejemplo, ejemplificación o con-

creción

1.7. RESUMEN

7

Se define así un nuevo paradigma de programación, en el que podemos tener diferentes
jerarquías y/o especializaciones, en forma de subclases y superclases, habilitando al
mismo tiempo el polimorfismo.

El refinamiento progresivo usado hasta ahora era un refinamiento orientado al flujo de
datos, que no favorece la reutilización de código. Con la programación orientada a objetos,
en cambio, las clases más generales pueden servirnos siempre para nuevos usos que las
requieran.

Los programas en P.O.O. manejan objetos que se comunican unos con otros mediante

el intercambio de mensajes.

El diseño en P.O.O. no es ya, pues, top-down sino bottom-up; en lugar de ir de lo
principal a lo específico se hace al contrario. De aquí la gran importancia de una correcta
identificación de los objetos que vayan a participar en nuestro proyecto.

1.7. Resumen

El concepto de Orientación a Objetos surge en torno a 1970 de mano de Alan Ray.
Xerox PARC fue una de los primeros interesados en lo que se quería imponer como un
nuevo paradigma de programación.

El primer lenguaje totalmente orientado a objetos fue Smalltalk, creado por Dyra-

book. El único “fallo” que le fue achacado fue la falta de una interface WIMP3.

Parecía que esta nueva concepción iba a cercarse alrededor de la IA y sus redes semánti-
cas (los objetos parecían adaptarse a sus directivas es parte de y es un) y marcos
(frames).

No obstante, pronto los demás lenguajes comenzaron a crear extensiones de sí mismos
intentando incorporar las características que se definían fundamentales para la O.O.: B.
Stroustrup, de los laboratorios Bell, construyó a partir de C un lenguaje C con clases, que
más tarde seróa conocido como C++4.

Pero no sólo C tuvo su extensión, también Lisp, con CLOS (Common Lisp Object

System) y muchos otros.

También se crearon lenguajes totalmente orientados a objetos como Java5, que in-
corporó los hoy tan populares applets, el garbage collector y sobre todo su característica
multiplataforma (bytecode).

Ahora mismo, está a punto de ver la luz la versión que Microsoft ha hecho del lenguaje
Java, que se llamará C# (pronunciado C sharp). Este lenguaje compila el código fuente a
un código interno (Intermediate Language, similar al bytecode) y posteriormente a código
máquina.

Hoy en día los lenguajes O.O. tienen la supremacía en el campo de la RAD (Rapid
Application Development), con ejemplos como Delphi, aunque algunos de los que
se usan no cumplen todos los requisitos (p. ej. Visual Basic), que se consideran sólo
basados en objetos.

3Windows Icons Mice Pointers.
4Existe una anécdota sobre el nombre del lenguaje C++: C surge de la evolucíon de B, un lenguaje
construido a partir de BCPL (Basic cpl), a su vez “hijo” de CPL (Combined Programming Lan-
guaje). Después de tener un B y un C, se hicieron apuestas sobre si el siguiente en la saga sería ’D’ (por
orden alfabético) o ’P’ (por BCPL). Stroustrup evitó el compromiso añadiendo el operador sucesivo a la
letra C, C++.

5Los creadores de Java en principio le llamaron Oak (roble), pero como el nombre ya estaba registrado,
le pusieron lo que en inglés americano significa coloquialmente “café”. Además, sus componentes se
denominan Java Beans, que no significa otra cosa que “granos de café”.

8

CAPÍTULO 1. EVOLUCI ÓN DE LOS LENGUAJES DE PROGRAMACI ÓN

Diferencia entre lenguajes orientados a y basados en objetos

Los Lenguajes Basados en Objetos poseen una sintaxis y una semántica que per-
miten la creación de objetos, pero no poseen todas las características necesarias para
ser considerados plenamente orientados a objetos. La característica más comúnmente no-
soportada suele ser la posibilidad de herencia (fallo de VB).

Dentro de los Lenguajes Orientados a Objetos se hace una distinción entre L.O.O.
puros (como Smalltalk, Eiffel, Java,. . . ), que aunque por ser más abstractos son más fáci-
les de manejar pero más lentos, no permiten otra forma de hacer las cosas salvo la correcta,
mientras que los llamados L.O.O. híbridos (C++, Object Pascal, CLOS, Prolog++,. . . )
mezclan la O.O. con otro paradigma (programación estructurada / funcional / lógica,. . . )
y a pesar de poder ser más fáciles de aprender, si se conocen aquéllos de los que derivan,
proclamarse más rápidos y eficientes, y ofrecer otro tipo de soluciones cuando la O.O. no
es lo más adecuado, no ofrecen toda la versatilidad y potencia de una completa O.O.

Capítulo 2

Elementos básicos de la Orientación
a Objetos

En un programa, tenemos objetos que se comunican entre sí, que tienen un determinado
estado interno, que pertenecen a una clase,. . . Pero ¿qué significan todos estos términos?
Eso es lo que definiremos en este tema.

2.1. Clases

Ya comentamos en el tema anterior que la relación clase - objeto era equiparable

a la relación tipo - variable (página 6).

A grandes rasgos, podemos decir que una clase es una plantilla que define cómo han
de ser los objetos que pertenezcan a ella. Se definen una serie de métodos, entre ellos
constructores, que permiten instanciar ó crear objetos de esa clase y manejarlos.

La definición formal de clase abarca dos aspectos:

Definición estructural: se define el estado y comportamiento de los objetos de

esa clase (atributos y métodos).

Propósito de creación de nuevos objetos: la propia clase ha de definir métodos

para crear sus objetos1.

En Java:

[MODIFICADORES] class Nombre [extends clase]

-----

-------

[implements interface,...]

----------

{

}

\\ Atributos

\\ Métodos

1Estos métodos especiales se denominan métodos constructores, como ya hemos comentado.

9

10

CAPÍTULO 2. ELEMENTOS B ÁSICOS DE LA ORIENTACI ÓN A OBJETOS

Donde los modificadores pueden ser:
∗ public → clases que son accesibles desde fuera del paquete (módulo2) en que está de-

finida.

∗ abstract → clases que no pueden instanciarse, sólo se definen para ser extendidas.
∗ final → clases que no pued