PDF de programación - Introducción a los objetos - Piensa en Java

1: Introducción
a los objetos

La génesis de la revolución de los computadores se encontraba en una máquina,
y por ello, la génesis de nuestros lenguajes de programación tiende a parecerse
a esa máquina.

Pero los computadores, más que máquinas, pueden considerarse como herramientas que permiten
ampliar la mente ("bicicletas para la mente", como se enorgullece de decir Steve Jobs), además de
un medio de expresión inherentemente diferente. Como resultado, las herramientas empiezan a pa-
recerse menos a máquinas y más a partes de nuestra mente, al igual que ocurre con otros medios
de expresión como la escritura, la pintura, la escultura, la animación o la filmación de películas. La
programación orientada a objetos (POO) es una parte de este movimiento dirigido a utilizar los com-
putadores como si de un medio de expresión s e tratara.

Este capítulo introducirá al lector en los conceptos básicos de la POO, incluyendo un repaso a los mé-
todos de desarrollo. Este capítulo y todo el libro, toman como premisa que el lector ha tenido expe-
riencia en algún lenguaje de programación procedural (por procedimientos), sea C u otro lenguaje.
Si el lector considera que necesita una preparación mayor en programación y/o en la sintaxis de C
antes de enfrentarse al presente libro, se recomienda hacer uso del CD ROM formativo Thinking in
C: Foundations for C++ and Java, que se adjunta con el presente libro, y que puede encontrarse tam-
bién la URL, http://www. BruceEckel.com.

Este capítulo contiene material suplementario, o de trasfondo (background). Mucha gente no se sien-
te cómoda cuando se enfrenta a la programación orientada a objetos si no entiende su contexto, a
grandes rasgos, previamente. Por ello, se presentan aquí numerosos conceptos con la intención de
proporcionar un repaso sólido a la POO. No obstante, también es frecuente encontrar a gente que
no acaba de comprender los conceptos hasta que tiene acceso a los mecanismos; estas personas
suelen perderse si no se les ofrece algo de código que puedan manipular. Si el lector se siente iden-
tificado con este último grupo, estará ansioso por tomar contacto con el lenguaje en sí, por lo que
debe sentirse libre de saltarse este capítulo -lo cual no tiene por qué influir en la comprensión que
finalmente se adquiera del lenguaje o en la capacidad de escribir programas en él mismo. Sin em-
bargo, tarde o temprano tendrá necesidades ocasionales de volver aquí, para completar sus nocio-
nes en aras de lograr una mejor comprensión de la importancia de los objetos y de la necesidad de
comprender cómo acometer diseños haciendo uso de ellos.

El progreso d e la abstracción

Todos los lenguajes de programación proporcionan abstracciones. Puede incluso afirmarse que la
complejidad de los problemas a resolver es directamente proporcional a la clase (tipo) y calidad de
las abstracciones a utilizar, entendiendo por tipo "clase", aquello que se desea abstraer. El lenguaje

2

Piensa en Java

ensamblador es una pequeña abstracción de la máquina subyacente. Muchos de los lenguajes de-
nominados "imperativos" desarrollados a continuación del antes mencionado ensamblador (como
Fortran, BASIC y C) eran abstracciones a su vez del lenguaje citado. Estos lenguajes supusieron una
gran mejora sobre el lenguaje ensamblador, pero su abstracción principal aún exigía pensar en tér-
minos de la estructura del computador más que en la del problema en sí a resolver. El programador
que haga uso de estos lenguajes debe establecer una asociación entre el modelo de la máquina (den-
tro del "espacio de la solución", que es donde se modela el problema, por ejemplo, un computador)
y el modelo del problema que de hecho trata de resolver (en el "espacio del problema", que es don-
de de hecho el problema existe). El esfuerzo necesario para establecer esta correspondencia, y el
hecho de que éste no es intrínseco al lenguaje de programación, es causa directa de que sea difícil
escribir programas, y de que éstos sean caros de mantener, además de fomentar, como efecto cola-
teral (lateral), toda una la industria de "métodos de programación".

La alternativa al modelado de la máquina es modelar el problema que se trata de resolver. Lenguajes
primitivos como LISP o APL eligen vistas parciales o particulares del mundo (considerando respec-
tivamente que los problemas siempre se reducen a "listas" o a "algoritmos"). PROLOG convierte to-
dos los problemas en cadenas de decisiones. Los lenguajes se han creado para programación basa-
da en limitaciones o para programar exclusivamente mediante la manipulación de símbolos gráficos
(aunque este último caso resultó ser excesivamente restrictivo). Cada uno de estos enfoques cons-
tituyc una solución buena para determinadas clases (tipos) de problemas (aquéllos para cuya snlii-
ción fueron diseñados), pero cuando uno trata de sacarlos de su dominio resultan casi impracti-
cables.

El enfoque orientado a objetos trata de ir más allá, proporcionando herramientas que permitan al
programador representar los elementos en el espacio del problema. Esta representación suele ser
lo suficientemente general como para evitar al programador limitarse a ningún tipo de problema es-
pecífico. Nos referiremos a elementos del espacio del problema, denominando "objetos" a sus re-
presentaciones dentro del espacio de la solución (por supuesto, también serán necesarios otros ob-
jetos que no tienen su análogo dentro del espacio del problema). La idea es que el programa pueda
autoadaptarse al lingo del problema simplemente añadiendo nuevos tipos de objetos, de manera que
la mera lectura del código que describa la solución constituya la lectura de palabras que expresan
el problema. Se trata, en definitiva, de una abstracción del lenguaje mucho más flexible y potente
que cualquiera que haya existido previamente. Por consiguiente, la PO0 permite al lector describir
el problema en términos del propio problema, en vez de en términos del sistema en el que se eje-
cutará el programa final. Sin embargo, sigue existiendo una conexión con el computador, pues cada
objeto puede parecer en sí un pequeño computador; tiene un estado, y se le puede pedir que lleve
a cabo determinadas operaciones. No obstante, esto no quiere decir que nos encontremos ante una
mala analogía del mundo real, al contrario, los objetos del mundo real también tienen características
y comportamientos.

Algunos diseñadores de lenguajes han dado por sentado que la programación orientada a objetos,
de por sí, no es adecuada para resolver de manera sencilla todos los problemas de programación, y
hacen referencia al uso de lenguajes de programación multiparadigmal.

' N. del autor: Ver Multiparadigrn Programming in Leda, por Timothy Budd (Addison-Wesley, 1995).

1: Introducción a los objetos

3

Alan Kay resumió las cinco características básicas de Smalltalk, el primer lenguaje de programación
orientado a objetos que tuvo éxito, además de uno de los lenguajes en los que se basa Java. Estas
características constituyen un enfoque puro a la programación orientada a objetos:

Todo es un objeto. Piense en cualquier objeto como una variable: almacena datos, permite
que se le "hagan peticiones", pidiéndole que desempeñe por sí mismo determinadas opera-
ciones, etc. En teoría, puede acogerse cualquier componente conceptual del problema a re-
solver (bien sean perros, edificios, servicios, etc.) y representarlos como objetos dentro de un
programa.

Un programa es un cúmulo de objetos que se dicen entre sí lo que tienen que hacer
mediante el envío de mensajes. Para hacer una petición a un objeto, basta con "enviarle un
mensaje". Más concretamente, puede considerarse que un mensaje en sí es una petición para
solicitar una llamada a una función que pertenece a un objeto en particular.

Cada objeto tiene su propia memoria, constituida por otros objetos. Dicho de otra ma-
nera, uno crea una nueva clase de objeto construyendo un paquete que contiene objetos ya
existentes. Por consiguiente, uno puede incrementar la complejidad de un programa, ocultán-
dola tras la simplicidad de los propios objetos.

Todo objeto es de algún tipo. Cada objeto es un elemento de una clase, entendiendo por "cla-
se" un sinónimo de "tipo". La característica más relevante de una clase la constituyen "el con-
junto de mensajes que se le pueden enviar".

Todos los objetos de determinado tipo pueden recibir los mismos mensajes. Ésta es una
afirmación de enorme trascendencia como se verá más tarde. Dado que un objeto de tipo "cír-
culo" es también un objeto de tipo "polígono", se garantiza que todos los objetos "círculo"
acepten mensajes propios de "polígono". Esto permite la escritura de código que haga re-
ferencia a polígonos, y que de manera automática pueda manejar cualquier elemento que en-
caje con la descripción de "polígono". Esta capacidad de suplantación es uno de los conceptos
más potentes de la POO.

Todo objeto tiene una interfaz

Aristóteles fue probablemente el primero en estudiar cuidadosamente el concepto de tipo; ha-
blaba de "la clase de los pescados o la clase de los peces". La idea de que todos los objetos, aún
siendo únicos, son también parte de una clase de objetos, todos ellos con características y com-
portamientos en común, ya fue usada en el primer lenguaje orientado a objetos, Simula-67, que
ya incluye la palabra clave clase, que permite la introducción de un nuevo tipo dentro de un pro-
grama.

Simula, como su propio nombre indica, se creó para el desarrollo de simulaciones, como el clásico
del cajero de un banco, en el que hay cajero, clientes, cuentas, transacciones y unidades monetarias
-un montón de "objetos". Todos los objetos que, con excepción de su estado, son idénticos duran-
te la ejecució