UNIVERSIDAD NACIONAL DE FORMOSA

Facultad de Administración, Economía y Negocios

Av. Gutnisky 3200 - Tel. Fax - (03717) 451792
3600 - Formosa - Argentina

UNIDAD TEMATICA 3

PROGRAMACION ORIENTADA
A OBJETO (POO)

CATEDRA
PROGRAMACION II (PARADIGMA PROCEDURAL)

CODIGO
201

CARRERA
LICENCIATURA EN TECNOLOGIAS DE LA INFORMACION Y LA COMUNICACION

REGIMEN
CUATRIMESTRAL

DOCENTE
PROF. TITULAR: A.U.S. AGUSTIN F. SANDOVAL
 Introducción
En este breve documento intentaremos dar una visión general de la Programación
Orientada al Objeto (POO o también del inglés OOP = Object Oriented Programming). No
hay acuerdo sobre cómo se debe traducir del inglés "Object Oriented Programming", si
como "Programación Orientada a Objetos" o como "Programación Orientada al Objeto".

Ya que la OOP no es un lenguaje de programación, puede aplicarse a cualquier lenguaje, y de

hecho hoy en día está disponible en mayor o menor medida en todos los lenguajes
tradicionales (C se ha convertido en C++, Pascal en Delphi, VB incorpora parte de la OOP)
y no aparece un lenguaje nuevo sin que incluya OOP (como es el caso de Java) . Es por esto
que intentaremos que todo lo que aquí se diga pueda ser aplicado a cualquier lenguaje OOP.

Sin embargo, cuando llegue el momento de escribir código, emplearemos una sintaxis híbrida
de C++ y Java que según la opinión del autor del curso es la que puede resultar más clara
independientemente del lenguaje al que se acaben aplicandos estos conocimientos.

Para empezar, rogaríamos al lector experimentado en programación, que dejase a un lado

todas sus ideas preconcebidas acerca de cómo debe realizarse un programa, la OOP tiene
muy poco que ver con su forma habitual de trabajo, e incluso de ver el mundo; de hecho, los no
programadores, captan mucho antes estas ideas, ya que no tienen prejuicios ni lastres
ideológicos que les frenen.
Tenga en cuenta que usted, programador o no, ya sabe qué es un objeto y cómo manipularlo,
lo lleva haciendo desde que nació; si entiende la similitud entre los objetos del mundo físico y
los informáticos, la OOP le parecerá cosa de niños, pero no nos llevemos a engaño, éste es el
punto más escabroso, hacer ver qué es la OOP, quitarnos todas las ideas preconcebidas sobre
programación tradicional.

Al autor, le costó más tiempo y esfuerzo llegar a verlo del que le hubiese costado a un neófito,
pero yo llevo mucho tiempo programando y mis conceptos eran demasiado rígidos. Necesité
por tanto una gran cantidad de "dinamita intelectiva" para hacer añicos la "roca granítica" de
mis ideas preconcebidas.
Conscientes de ello, hemos considerado como la mejor aproximación exponer una serie de
ejemplos y comparaciones de índole totalmente diferente. Algunas de ellas, las últimas, son
para los programadores, el lector neófito, puede prescindir de estas, no son necesarias en
absoluto para entender plenamente la OOP, pero a aquellos que conocen algún lenguaje de
programación pueden serles útiles para entender esta técnica. Estos ejemplos los
expondremos en el próximo capítulo, cuando entremos de lleno en OOP.
 Breve revisión histórica
En este capítulo vamos a llevar a cabo una introducción muy general sobre la evolución de los
lenguajes en informática, para entrar posteriormente y más a fondo, en describir la aparición, los
principios teóricos y la evolución de la Programación Orientada al Objeto. Esta introducción no
pretende ser un libro de referencia técnica de informática: hemos preferido dar una visión general
y clara para el neófito, con lo que ello pueda acarrear de inexactitud, antes que perder la visión de
conjunto.

Empezaremos por hacer una revisión de la evolución de los leguajes de programación,

continuaremos explicando qué es la OOP para terminar haciendo una breve revisión histórica de
la misma.

Evolución de los lenguajes de programación

Toda la historia de los lenguajes de programación se ha desarrollado en base a una sola idea
conductora: hacer que la tarea de realizar programas para ordenadores sea cada vez lo más
simple, flexible y portable posible.

La OOP supone, no solo un nuevo paso hacia ese fin, sino que además, a nuestro juicio, es el
más importante acaecido hasta el momento. Como nos comenta Eckel: "A medida que se van
desarrollando los lenguajes, se va desarrollando también la posibilidad de resolver
problemas cada vez más complejos. En la evolución de cada lenguaje, llega un momento
en el que los programadores comienzan a tener dificultades a la hora de manejar
programas que sean de un cierto tamaño y sofisticación." (Bruce Eckel, "Aplique C++" , p.
5 Ed. McGrow-Hill).
Esta evolución en los lenguajes, ha venido impulsada por dos motores bien distintos:
• Los avances tecnológicos
• Los avances conceptuales (de planteamiento)
• Los avances en cuanto a enfoque de la programación

Evolución en cuanto a la tecnología

Como usted probablemente sabrá, un ordenador no es más que un conjunto de
microinterruptores, estos pueden estar apagados o encendidos (por lo que les llamamos
elementos biestado). En un principio estos interruptores eran relés, que no es más que un
electroimán que puede cerrar o abrir un circuito eléctrico. Si están apagados (no dejan pasar
corriente), decimos que su estado es cero y en caso contrario uno.

Un programa de ordenador no es más que una sucesión de instrucciones que se ejecutarán

secuencialmente, es decir, una detrás de otra. Por tanto, como la forma de programarlos es
introduciendo secuencias de ceros y unos (lo que llamamos bits); puede imaginarse la gran
probabilidad que existe de error al introducir sucesiones enormemente largas; además, una vez
cometido un error, intentar encontrarlo y corregirlo puede llevarnos antes al manicomio con un
grave cuadro de psicosis, que a la solución del problema.
De hecho, desde hace ya muchos años, los microprocesadores, que, como probablemente
sabrá, son la maquinaria ejecutora de los ordenadores, se fabrican para ser programados, no en
binario (secuencia de unos y ceros), sino en hexadecimal (un número hexadecimal equivale a 16
ceros o unos).
Cronológicamente el primer avance importante vino con la aparición de los lenguajes
ensambladores . A estos lenguajes los llamamos de "bajo nivel", ya que se hallan estrechamente
ligados a la forma de trabajo de la máquina con la que programamos y se opera con ellos de
modo muy similar a como se hace cuando trabajamos en hexadecimal.

Quizás usted pueda pensar que no hay gran diferencia entre programar en hexadecimal (o en
binario), y hacerlo a través de un ensamblador, y es cierto, pero este logro no lo es tanto en
cuanto al modo de trabajo (que seguía siendo precario y tedioso) como en cuanto a la nueva
concepción que ello implica: por primera vez aquello que nosotros escribimos no es entendible
directamente por la máquina, sino que debe ser previamente traducido para que la máquina lo
entienda.
Un lenguaje ensamblador lo único que hace es transcribir unos nemónicos (palabras fáciles de
recordar) a la secuencia ceros y unos a los que el nemónico representa y que sí son entendibles
por la máquina.
Por ejemplo, supongamos que deseamos almacenar un número en uno de los registros del
microprocesador (un caso frecuente cuando se programa a bajo nivel). Supongamos que el
número, para simplificar las cosas es el 4 (tiene la misma notación en decimal que en
hexadecimal) y el registro el AX (uno de los registros de la familia de microprocesadores 80- de la
marca Intel), la instrucción tendría un aspecto algo así:

HEXADECIMAL ENSAMBLADOR
1A 01 04 MOV AX, 04

Como podemos apreciar, es más fácil de recordar la segunda notación que la primera,
haciéndose el código más inteligible.

El problema de los lenguajes ensambladores es que se hallan fuertemente comprometidos con la

máquina. Un programa escrito en lenguaje ensamblador solo podrá ser ejecutado en la máquina
donde fue diseñado.

El siguiente paso, vino con la aparición de los lenguajes de alto nivel.

El proceso de desarrollo de una aplicación con un lenguaje de alto nivel es mucho más rápido,
simple y, por tanto, resulta más fácil detectar y corregir errores. Esto se debe principalmente a
dos factores: por un lado, cada instrucción que escribimos en lenguaje de alto nivel puede
equivaler a varias decenas e incluso cientos de instrucciones en ensamblador; por otra parte, la
sintaxis de las instrucciones y los nemónicos que usamos se parecen algo más al lenguaje
cotidiano (sobre todo si fuésemos angloparlantes).
Para hacernos una idea, diremos que realizar un programa que en un lenguaje de alto nivel nos
puede llevar pocos días, en ensamblador es tarea de meses. Si tenemos esto en cuenta,
comprenderemos que después de escribir un programa en código máquina y de haberlo
depurado para eliminar los errores (bugs en terminología informática), a nadie le queden ganas
de ponerse a re-escribirlo para otra máquina distinta. Con lo que la portabilidad queda mermada
considerablemente. Hecho que no debe ocurrir con un lenguaje de alto nivel.
A estas alturas, es posible que usted esté pensado que todo esto es demasiado bonito para ser
cierto y que en algún lugar debe estar el problema. Efectivamente, no nos llevemos a engaño,
todo esto al final, se queda en papel mojado y buenas intenciones, debe ser que al dios de la
computación le agrada hacernos la vida complicada.

La cuestión tiene dos vertientes bien distintas: por un lado, los programas realizados con
lenguajes de alto nivel, realizan los mismo procesos de un modo más lento que de haberlos
escrito con uno de bajo nivel, este problema no es demasiado gravoso si echamos un vistazo a la
evolución en la potencia de cálculo de las máquinas en los últimos diez años. Salvo para
programas muy específicos, o de gran rendimiento, no habría ningún problema, en escribir
nuestras aplicaciones en un lenguaje de alto o bajo nivel.
¿Dónde está el problema entonces? se preguntará usted. La respuesta es que está en la
portabilidad.

En teoría, y solo en teoría, puesto que un lenguaje de alto nivel es independiente de la máquina
donde se ejecute, el mismo código que escribimos para una máquina puede ser traducido al
lenguaje hexadecimal en esa máquina o en otra cualquiera que disponga de traductor para ese
lenguaje.

Por ejemplo, si yo escribo un programa en lenguaje BASIC para un ordenador, este mismo
programa podría ejecutarse en cualquier otra máquina que dispusiese de traductor de BASIC
para ella. Pero aquí aparece la torre de Babel de la informática. Existen traductores de lenguaje
BASIC para multitud de máquinas diferentes, el problema reside en que cada máquina tiene un
dialecto del lenguaje BASIC distinto a los demás, con lo que la portabilidad se hace imposible.
¿Y por qué ocurre esto? Eso ya son cuestiones de marketting, política de empresas y sociedad
de consumo y libre mercado, algo que tiene muy poco que ver con los investigadores y las
buenas intenciones.

Evolución en cuanto a la conceptualización

El primer avance en metodología de programación, vino con la Programación Estructurada
(en este concepto vamos a incluir el propio y el de técnicas de Programación con Funciones
-también llamado procedural-, ya que ambos se hallan íntimamente relacionados, no
creemos, que se pueda concebir la programación estructurada sin el uso masivo de
funciones).

La programación en ensamblador es lineal, es decir, las instrucciones se ejecutan en el

mismo orden en que las escribimos. Podemos, sin embargo, alterar este orden haciendo
saltos desde una instrucción a otro lugar del programa distinto a la instrucción que le sigue a
la que se estaba procesando.

El BASIC tradicional también trabaja de este modo. Este sistema de trabajo es complicado, ya
que obliga al programador a retener en su cabeza permanentemente todo el código escrito
hasta un momento determinado para poder seguir escribiendo el programa; además a la hora
de leerlo, el programador se pierde con facilidad porque debe ir saltando continuamente de
unos trozos de código a otros.
Veamos un ejemplo típico de cómo se abordaría una misma tarea desde las dos
perspectivas. La tarea consiste en mostrar los números del 1 a 10. Lo explicaremos en
pseudo-código (exponer los pasos a realizar en lenguaje natural, en lugar de hacerlo en
alguno de los lenguajes de programación existentes) para que resulte más comprensible:

Programación lineal
Cada línea de programa debe ir precedida de un identificador (una etiqueta) para poder
referenciarla, para este ejemplo hemos utilizado números, aunque podría utilizarse cualquier
otro identificador:
1. Racer una variable igual a 0
2. Sumar 1 a esa variable
3. Mostrar la variable
4. Si la variable es 100 -> terminar, Si_no -> saltar a 1:
Programación estructurada
Racer una variable igual a 0
Mientras que sea menor que 100 -> sumar 1 y mostrarla

Lo importante aquí, es que cuando escribimos un programa usando las técnicas de

programación estructurada, los saltos están altamente desaconsejados, por no decir
prohibidos; en cambio en BASIC, por ejemplo, son muy frecuentes (todos conocemos el
prolífico GOTO <nLínea> ), lo que no es nada conveniente si queremos entender algo que
escribimos hace tres meses de forma rápida y clara.

De hecho, cuando el traductor (ya sea intérprete o compilador) cambia nuestro programa a
código máquina, lo convierte a estilo lineal, pero eso es asunto de la máquina, nosotros
escribimos y corregimos nuestro programa de un modo claro, y podemos seguir el flujo de la
información con facilidad.

Lo que se intenta, es que el programador pueda hacer programas cada vez más extensos sin
perderse en un entramado de líneas de código interdependientes. Un programa en estilo lineal
se parece a la red neuronal del cerebro, si usted ha visto alguna vez una foto de estas, no lo
habrá olvidado: en esa maraña de neuronas y conexiones nerviosas no hay quien se entienda,
y si no que se lo pregunten a los neurofisiólogos.

Para evitar esto, junto con la programación estructurada aparece un concepto que nos
permite abarcar programas más amplios con menor esfuerzo: el de función.

La idea es muy simple: muchas veces realizo procesos que se repiten y en los que sólo
cambia algún factor, si trato ese proceso como un subprograma al que llamo cada vez que lo
necesito, y cada vez que lo llamo puedo cambiar ese factor, estaré reduciendo el margen de
error, al reducir el número de líneas que necesito en mi programa, ya que no tengo que repetir
todas esas líneas cada vez que quiera realizar el proceso, con una sola línea de llamada al
subprograma será suficiente; además, de haber algún fallo en este proceso el error queda
circunscrito al trozo de código de la función.
Así, las funciones podemos entenderlas como unas cajas negras, que reciben y devuelven
valores. Solo tengo que programarlas una vez, las puedo probar por separado y comprobar
que funcionan correctamente, una vez terminadas puedo olvidarme de cómo las hice y
usarlas siempre que quiera.

Simultáneamente al concepto de función aparece el de variables de ámbito reducido. Todos

recordaremos nuestros nefastos días del BASIC, en los que cualquier variable usada en el
programa, era conocida en todo el programa. Resultado: cuando habíamos definido 500
variables, no nos acordábamos para qué servía cada una ni que nombres habíamos usado y
cuáles no. Con un lenguaje estructurado, las variables son conocidas solo por aquellas partes
del programa donde nos interesa que lo sean; pudiendo re-usar los nombres de las variables
sin que haya colisión, siempre que estas se utilicen en ámbitos distintos.
PROGRAMACIÓN ORIENTADA AL OBJETO
Por último, llegamos al más reciente avance, la OOP, que nos ofrece mucho mayor dominio
sobre el programa liberándonos aún más de su control. Hasta ahora, el control del programa
era tarea del programador, si usted ha realizado algún programa de magnitud considerable lo
habrá padecido. El programador tenía que controlar y mantener en su mente cada proceso
que se realizaba y los efectos colaterales que pudieran surgir entre distintos procesos, lo que
llamamos colisiones. En OOP, el programa se controla a sí mismo y la mente del
programador se libera enormemente pudiendo realizar aplicaciones mucho más complejas al
exigir menor esfuerzo de atención, ya que los objetos son entidades autónomas que se
controlan (si han sido creados correctamente) a sí mismos. Esto es posible principalmente
porque los objetos nos impiden mezclar sus datos con otros métodos distintos a los suyos.
En programación estructurada, una función trabaja sobre unos datos, y no debería modificar
datos que no le corresponde hacer, pero de eso tiene que encargarse el programador, en
OOP es el propio sistema de trabajo el que impide que esto ocurra. Además, la re-usabilidad
del código escrito es mucho mayor que con el uso de funciones, y las portabilidad es también
mayor.
Pero este es el tema del que hablaremos en el resto del libro.

Evolución en cuanto al enfoque

La evolución de los lenguajes de programación, en cuanto a enfoque es también una
evolución conceptual, pero ésta es tan profunda que supone un cambio drástico en cuanto al
modo de concebir el tratamiento de la programación.
En este sentido, y dependiendo del autor a quien se consulte, existen dos o tres enfoques
diferentes:
• Programación procedural
• Programación declarativa
• Programación orientada a objetos

Programación Procedural
Casi todos los lenguajes que conocemos trabajan de forma procedural. Java, C, Pascal,
BASIC, Cobol, Fortran, APL, RPG, Clipper, etc.
En ellos, debemos establecer, hechos (datos), reglas para el manejo de esos datos y de
decisión y tenemos que decirle al lenguaje cómo alcanzar el objetivo que se persigue. Es
decir, donde buscar la información, cómo manipularla, cuando parar, etc.
Si usted es programador de algún lenguaje procedural, todo esto le parecerá obvio, pero no
funciona así con los lenguajes declarativos.
No vamos a ahondar más en estos lenguajes, porque suponemos que usted conoce algo de
ellos.

Programación Declarativa
Los lenguajes más conocidos que existen hasta ahora, salvo PROLOG, son todos
procedurales, éste es declarativo.
ProLog es acrónimo de PROgramming in LOGic. Este lenguaje fue desarrollado en la
universidad de Marsella hacia 1970 por Alan Clomerauer y sus colegas.

ProLog, se basa en manipulaciones lógicas, utiliza la lógica proposicional -lógica de

predicados- para realizar sus deducciones.

En ProLog no programamos, sino que declaramos hechos, es la maquinaria del lenguaje

quien se encargará de extraer las conclusiones que resulten inferibles de estos hechos.

A esta maquinaria se le llama motor de inferencias, que es, por otro lado, el corazón de un
Sistema Experto. Probablemente de este tipo de programas -los más famosos de la
Inteligencia Artificial-, habrá usted oído hablar.

Programación Orientada al Objeto

Nosotros disentimos parcialmente de autores como Manuel Fonseca y Alfonso Alcalá, que
incluyen la OOP como un nuevo enfoque. Ya que, entre otras cosas y principalmente, la OOP
es un conjunto de técnicas.

Aclaremos la diferencia entre técnica y lenguaje de programación:

Una técnica de programación no es, obviamente, un lenguaje, pero puede aplicarse a
cualquier lenguaje. Podemos definirlo como un conjunto de reglas a seguir para hacernos la
tarea de programar más fácil. Son consejos de expertos programadores, que tras años de
trabajo, han acumulado una gran experiencia. Pero estas técnicas, son obviamente,
independientes del lenguaje en que trabajemos.
Un lenguaje de programación, es algo que todos más o menos conocemos: un conjunto de
instrucciones entendibles directamente o traducibles al lenguaje del ordenador con el que
trabajemos; combinando estas instrucciones realizamos programas.
Es cierto sin embrago, que para poder aplicar OOP al 100%, es necesario que el lenguaje nos
proporcione una serie de mecanismos inherentes al propio lenguaje.

En cualquier caso, la OOP es casi 100% procedural y, desde luego, no es en absoluto

declarativa.

De todos modos, el autor de este libro comparte en cierto modo la teoría de los tres enfoques.
El problema, es el mismo que aparece a la hora de dilucidar donde acaba un color y
comienza otro en el arco iris. Siempre que hacemos una clasificación de la realidad, nos
encontramos con elementos que son fronterizos entre una clase y otra y son de difícil
ubicación. Sin embargo, no queda más remedio, a efectos didácticos que realizarlas. Nos
sentimos más inclinados limitar los enfoques en programación a los dos primeros, dejando
fuera a la OOP.
Posiblemente, y con el tiempo, reconsideremos esta postura y estemos de acuerdo con estos
y otros autores; al fin y al cabo, la OOP aún no está completamente asentada, y no sabemos
dónde nos habrá llevado en los próximos años.

¿Qué es La OOP?
Comenzaremos dando una definición por exclusión de lo que es la OOP, es decir, vamos a
decir primero qué no es la OOP, para, luego, intentar dar una definición de lo que es.
LA OOP no es:
Un sistema de comunicación con los programas basados en ratones, ventanas, iconos, etc.
Puesto que, normalmente, los lenguajes de OOP suelen presentar estas características y
puesto que habitualmente estos entornos suelen desarrollarse con técnicas de OOP, algunas
personas tienden a identificar OOP y entornos de este tipo. De igual modo a como se tendía a
identificar la inteligencia artificial con lenguajes como LISP o PROLOG. El autor de este libro
asegura haber visto más de un programa escrito en estos lenguajes que no tenía nada de
inteligente y mucho menos de inteligencia artificial.
No es un lenguaje . De hecho las técnicas de OOP pueden utilizarse en cualquier lenguaje
conocido y los que están por venir, aunque estos últimos, al menos en los próximos años,
incluirán facilidades para el manejo de objetos. Desde luego, que en los lenguajes que prevén
el uso de objetos la implementación de las técnicas de OOP resulta mucho más fácil y
provechosa que los otros. Pero del mismo modo a lo comentado en el punto anterior, se
pueden utilizar estos lenguajes sin que los programas resultantes tengan nada que ver con la
OOP.
Como ya hemos comentado, la OOP son un conjunto de técnicas que nos permiten
incrementar enormemente nuestro proceso de producción de software; aumentando
drásticamente nuestra productividad por un lado y permitiéndonos abordar proyectos de
mucha mayor envergadura por otro.

Usando estas técnicas, nos aseguramos la re-usabilidad de nuestro código, es decir, los
objetos que hoy escribimos, si están bien escritos, nos servirán para "siempre".
Hasta aquí, no hay ninguna diferencia con las funciones, una vez escritas, estas nos sirven
siempre. Pero es que, y esto sí que es innovador, con OOP podemos re-usar ciertos
comportamientos de un objeto, ocultando aquellos otros que no nos sirven, o redefinirlos para
que los objetos se comporten de acuerdo a las nuevas necesidades.

Veamos un ejemplo simple: si tenemos un coche y queremos que sea más rápido, no
construimos un coche nuevo; simplemente le cambiamos el carburador por otro más potente,
cambiamos las ruedas por otras más anchas para conseguir mayor estabilidad y le añadimos
un sistema turbo. Pero seguimos usando todas las otras piezas de nuestro coche.

Desde el punto de vista de la OOP ¿Qué hemos hecho?

Hemos modificado dos cualidades de nuestro objeto (métodos): el carburador y las ruedas.
Hemos añadido un método nuevo: el sistema turbo.
En programación tradicional, nos hubiésemos visto obligados a construir un coche nuevo por
completo.
Dicho en términos de OOP, si queremos construir un objeto que comparte ciertas cualidades
con otro que ya tenemos creado, no tenemos que volver a crearlo desde el principio;
simplemente, decimos qué queremos usar del antiguo en el nuevo y qué nuevas
características tiene nuestro nuevo objeto.
Aún hay más, con OOP podemos incorporar objetos que otros programadores han construido
en nuestros programas, de igual modo a como vamos a una tienda de bricolaje y compramos
piezas de madera para ensamblarlas y montar una estantería o una mesa. Pero, es que
además podemos modificar los comportamientos de los objetos construidos por otros
programadores sin tener que saber cómo los han construido ellos.
Como puede ver, esto supone realmente una nueva concepción en el desarrollo de
programas, algo radicalmente nuevo y de una potencia y versatilidad hasta ahora
inimaginables. Si usted es programador de la "vieja escuela" le parecerá increíble, sin
embargo, y como podrá comprobar, es totalmente cierto.

Breve historia de la OOP

Los conceptos de clase y herencia fueron implementados por vez primera en el lenguaje
Simula 67 (el cual no es sino una extensión de otro más antiguo, llamado Algol 60), este fue
diseñado en 1967 por Ole-Johan Dhal y Krysten Nygaard en la Universidad de Oslo y el
Centro de Computación Noruego (Norsk Regnesentral).

La historia de Simula, que es como se le llama coloquialmente, es tan frecuente como

desafortunada. Fue diseñado como un lenguaje de propósito general y pasó por el mundo de
la informática sin pena ni gloria durante años. Fue mucho después, con la aparición de otros
lenguajes que se basaban en estos innovadores conceptos (Smalltalk y sobretodo C++),
cuando se le reconoció a los creadores de Simula su gran mérito. Sin embargo, Simula sigue
sin usarse porque estos conceptos han sido ampliados y han aparecido otros nuevos que le
dan mayor potencia y flexibilidad a los conceptos originales de clase y herencia, conformando
lo que hoy entendemos por Programación Orientada al Objeto.
Aunque Simula fue el padre de todo este revuelo, ha sido Smalltalk quién dio el paso definitivo
y es éste el que debemos considerar como el primer lenguaje de programación orientado a
objetos. Smalltalk fue diseñado (cómo no) en el Palo Alto Research Center (PARC) de Xerox
Corporation's, en California.
Este ha sido uno de los centros de investigación que más avances ha dado al la informática
en toda su historia; fue aquí donde se desarrolló el entorno de ventanas que hoy usan
Windows en MS-DOS y XWindows en UNIX, los famosos ratones como dispositivos de
entrada de datos o interfaces de usuario como el DataGlobe. Según últimas noticias, ahora
andan desarrollando unos nuevos conceptos de sistemas operativos con imágenes
tridimensionales en movimiento que serán los que probablemente utilizaremos dentro de
algunos años.

En este centro de investigación de Palo Alto, a comienzos de los 70, el proyecto iniciado por
Alan Kay vio la luz con el nombre de Smalltalk. Lo que había empezado como un proyecto de
desarrollo de un lenguaje de propósito general acabó siendo mucho más que eso,
convirtiéndose en el origen de la, hasta ahora, última y más importante revolución en el
desarrollo de software.
Smalltalk incluye no solo un lenguaje para el desarrollo de aplicaciones, sino que además
incorpora herramientas de ayuda al desarrollo (p.ej. manejadores de árboles de clases,
examinadores de objetos, etc.) y un completo interfaz gráfico de usuario.

El último gran paso, a nuestro juicio, lo dio Bjarne Stroustrup con la creación del C++, quizás
el lenguaje de programación orientado a objetos más usado actualmente. Este, fue definido
en 1986 por su autor en un libro llamado The C++ Programming Language, de cita y
referencia obligadas cuando se habla de OOP. Tan importante es esta publicación, que
cuando se habla de C++, a este libro se le llama "El Libro". Cuando algún experto se
encuentra con alguna duda sobre cómo debería ser un lenguaje orientado al objeto recurre a
él, y si no encuentra solución, se dirige directamente a Stroustrup.
La importancia del C++ radica, en que, abandonando ciertos requerimientos de los lenguajes
de cuarta generación con tecnología OOP como son Smalltalk o Actor, ha conseguido darle
una gran potencia y flexibilidad al más famoso lenguaje, el C.
Llegados a este punto se hace necesario aclarar que los lenguajes de OPP, podemos
clasificarlos en puros e híbridos . Diremos que un lenguaje es OOP puro, cuando se ajusta
completamente a los principios que esta técnica propone y contempla la posibilidad de trabajar
exclusivamente con clases. Diremos que un lenguaje es híbrido de OOP y algún otro, cuando
ese lenguaje, que normalmente existía antes de la aparición de la OOP, incorpora en mayor o
menor medida facilidades para trabajar con clases.
De este modo, C++ es un lenguaje OOP híbrido. De hecho, C++ no incorpora todas las
características de un lenguaje OOP, y no lo hace principalmente, porque es un lenguaje
compilado y ello impide que se resuelvan ciertas referencias en tiempo de compilación
necesarias para dotar a las clases de algunas de sus cualidades puramente OOP (a menos
que se le dote de un motor OOP interno, el cual tiene en parte, pero esto es harina de otro
costal y no forma parte de la finalidad de este libro).

Hoy en día, casi todos los lenguajes más usados en los 80 se han reconvertido en mayor o
menor medida a la OOP, y han aparecido otros nuevos. Veámoslos rápidamente:

C ha pasado a llamarse C++. Es la mejor implementación OOP sobre un lenguaje compilado

existente en este momento. Su punto más conflictivo no obstante no su total implementación
OOP, sino el hecho de permitir herencia múltiple, lo que, según los teóricos, no es muy
aconsejable.

Pascal ha sido reciclado por Borland, pasando a llamarse Delphi . Tiene una implementación
OOP bastante buena, pero al no permitir sobrecarga de funciones pierde una de las
características de OOP: Polimorfismo.

Basic ha pasado a llamarse Visual Basic en manos de Microsoft. Este, aun siendo uno de
los lenguajes más famosos del momento, no es un lenguaje OOP completo, ya que no incluye
la característica más importante de la OOP: la Herencia.
Java es la estrella de los últimos años: es pura OOP, impecablemente concebido e
implementado por Sun, y al que sólo se le puede achacar (si es que nos ponemos
quisquillosos) que no dispone de sobrecarga de operadores, cualidad que de los citados aquí
sólo dispone C++.
Incluso el viejo Cobol se ha reciclado, existiendo en estos momentos más de una versión de
Cobol que incluye OOP.
PROGRAMACIÓN ORIENTADA AL OBJETO

El concepto de Sistema de Programación Orientado al Objeto -Object Oriented Programming

System (OOPS)-, y que nosotros llamamos OOP, agrupa un conjunto de técnicas que nos
permiten desarrollar y mantener mucho más fácilmente programas de una gran
complejidad.

Veamos ahora cuales son los conceptos relacionados con la OOP.

Conceptos básicos
Estudiaremos los conceptos de Clase, Objeto, Herencia, Encapsulación y Polimorfismo. Estas
son las ideas más básicas que todo aquel que trabaja en OOP debe comprender y manejar
constantemente; es por lo tanto de suma importancia que los entienda claramente. De todos
modos, no se preocupe si al finalizar el presente capítulo, no tiene una idea clara de todos o
algunos de ellos: con el tiempo los irá asentando y se ira familiarizando con ellos,
especialmente cuando comience a trabajar creando sus propias clases y jerarquías de clases.

Definición de Clase
Una clase, es simplemente una abstracción que hacemos de nuestra experiencia sensible. El
ser humano tiende a agrupar seres o cosas -objetos- con características similares en
grupos -clases-. Así, aun cuando existen por ejemplo multitud de vasos diferentes, podemos
reconocer un vaso en cuanto lo vemos, incluso aun cuando ese modelo concreto de vaso no lo
hayamos visto nunca. El concepto de vaso es una abstracción de nuestra experiencia sensible.

Quizás el ejemplo más claro para exponer esto lo tengamos en las taxonomías; los biólogos
han dividido a todo ser (vivo o inerte) sobre la tierra en distintas clases.

Tomemos como ejemplo una pequeña porción del inmenso árbol taxonómico:
Los llaman a cada una de estas parcelas reino, tipo, clase, especie, orden, familia, género,
etc.; sin embargo, nosotros a todas las llamaremos del mismo modo: clase. Así, hablaremos
de la clase animal, clase vegetal y clase mineral, o de la clase félidos y de las clases leo (león)
y tigris (tigre).
Cada clase posee unas cualidades que la diferencian de las otras. Así, por ejemplo, los
vegetales se diferencian de los minerales -entre otras muchas cosas- en que los primeros son
seres vivos y los minerales no. De los animales se diferencian en que las plantas son capaces
de sintetizar clorofila a partir de la luz solar y los animales no.
Como vemos, el ser humano tiende, de un modo natural a clasificar los objetos del mundo
que le rodean en clases; son definiciones estructuralistas de la naturaleza al estilo de la
escuela francesa de Saussure.

Prosigamos con nuestro ejemplo taxonómico y bajemos un poco en este árbol de clases.

Situémonos en la clase felinos (felis), aquí tenemos varias subclases (géneros en palabras de
los biólogos): león, tigre, pantera, gato, etc. cada una de estas subclases, tienen
características comunes (por ello los identificamos a todos ellos como felinos) y
características diferenciadoras (por ello distinguimos a un león de una pantera), sin embargo,
ni el león ni la pantera en abstracto existen, existen leones y panteras particulares, pero
hemos realizado una abstracción de esos rasgos comunes a todos los elementos de una
clase, para llegar al concepto de león, o de pantera, o de felino.
La clase león se diferencia de la clase pantera en el color de la piel, y comparte ciertos
atributos con el resto de los felinos -uñas retráctiles por ejemplo- que lo diferencian del resto
de los animales. Pero la clase león, también hereda de las clases superiores ciertas
cualidades: columna vertebral (de la clase vertebrados) y es alimentado en su infancia por
leche materna (de la clase mamíferos).

Vemos cómo las clases superiores son más generales que las inferiores y cómo, al ir bajando
por este árbol, vamos definiendo cada vez más (dotando de más cualidades) a las nuevas
clases.

Hay cualidades que ciertas clases comparten con otras, pero no son exactamente iguales en
las dos clases. Por ejemplo, la clase hombre, también deriva de la clase vertebrado, por lo
que ambos poseen columna vertebral, sin embrago, mientras que en la clase hombre se halla
en posición vertical, en la clase león la columna vertebral está en posición horizontal.
En OOP existe otro concepto muy importante asociado al de clase, el de "clase abstracta".
Una clase abstracta es aquella que construimos para derivar de ella otras clases, pero de la
que no se puede instanciar. Por ejemplo, la clase mamífero, no existe como tal en la
naturaleza, no existe ningún ser que sea tan solo mamífero (no hay ninguna instanciación
directa de esa clase), existen humanos, gatos, conejos, etc. Todos ellos son mamíferos, pero
no existe un animal que sea solo mamífero.

Del mismo modo, la clase que se halla al inicio de la jerarquía de clases, normalmente es
creada sólo para que contenga aquellos datos y métodos comunes a todas las clases que de
ella derivan: Son clases abstractas. En árboles complejos de jerarquías de clases, suele
haber más de una clase abstracta.

Este es un concepto muy importante: el de "clase abstracta". Como hemos dicho, una clase
abstracta es aquella que construimos para derivar de ella otras clases, pero de la que no se
puede instanciar. Por ejemplo, la clase mamífero, no existe como tal en la naturaleza, no
existe ningún ser que sea tan solo mamífero (no hay ninguna instanciación directa de esa
clase), existen humanos, gatos, conejos, etc. Todos ellos son mamíferos, pero no existe un
animal que sea solo mamífero.
Por último, adelantemos algo sobre el concepto de objeto.
El león, como hemos apuntado antes, no existe, igual que no existe el hombre; existen leones
en los circos, en los zoológicos y, según tenemos entendido, aún queda alguno en la sabana
africana. También existen hombres, como usted, que está leyendo este libro (hombre en un
sentido neutro, ya sea de la subclase mujer o varón), o cada uno de los que nos encontramos
a diario en todas partes.
Todos estos hombres comparten las características de la clase hombre, pero son diferentes
entre sí, en estatura, pigmentación de la piel, color de ojos, complexión, etc. A cada uno de
los hombres particulares los llamamos "objetos de la clase hombre". Decimos que son objetos
de tipo hombre o que pertenecen a la clase hombre. Más técnicamente, José Luis Aranguren
o Leonardo da Vinci son instanciaciones de la clase hombre; instanciar un objeto de una clase
es crear un nuevo elemento de esa clase, cada niño que nace es una nueva instanciación a la
clase hombre.

Definición de Objeto
Según el Diccionario del Uso del Español de María Moliner (Ed. Gredos, 1983), en la tercera
acepción del término objeto podemos leer: "Con respecto a una acción, una operación mental,
un sentimiento, etc., cosa de cualquier clase, material o espiritual, corpórea o incorpórea, real
o imaginaria, abstracta o concreta, a la cual se dirigen o sobre la que se ejercen."

No se asuste, nuestra definición de objeto, como podrá comprobar es mucho más fácil. En
OOP, un objeto es un conjunto de datos y métodos; como imaginamos que se habrá quedado
igual, le vamos a dar más pistas.

Los datos son lo que antes hemos llamado características o atributos, los métodos son los
comportamientos que pueden realizar.

Lo importante de un sistema OOP es que ambos, datos y métodos están tan intrínsecamente
ligados, que forman una misma unidad conceptual y operacional. En OOP, no se pueden
desligar los datos de los métodos de un objeto. Así es como ocurre en el mundo real.

Vamos ahora a dar una serie de ejemplos en los que nos iremos acercando paulatinamente a
los objetos informáticos. Los últimos ejemplos son para aquellos que ya conocen Java y/o C;
sin embargo, estos ejemplos que exigen conocimientos informáticos, no son imprescindibles
para entender plenamente el concepto de clase y el de objeto.

Observe que aunque los datos y los métodos se han enumerado verticalmente, no existe
ninguna correspondencia entre un dato y el método que aparece a su derecha, es una simple
enunciación.

Ejemplo 1
Tomemos la clase león de la que hablamos antes y veamos cuales serían algunos de sus
datos y de sus métodos.
Datos Métodos
Color Desplazarse
Tamaño Masticar
Peso Digerir
Uñas retráctiles Respirar
Colmillos Secretar hormonas
Cuadrúpedo Parpadear
etc. etc.
Ejemplo 2
Nuestros objetos (los informáticos), como hemos comentado antes, se parecen mucho a los del
mundo real, al igual que estos, poseen propiedades (datos) y comportamientos (métodos).
Tomemos para nuestro ejemplo un cassette. Veamos cómo lo definiríamos al estilo de OOP.

Datos Métodos
Peso Rebobinar la cinta
Dimensiones Avanzar la cinta
Color Grabar
Potencia Reproducir
etc. etc.

Ejemplo 3
Pongamos otro ejemplo algo más próximo a los objetos que se suelen tratar en informática: un
recuadro en la pantalla.
El recuadro pertenecería a una clase a la llamaremos marco . Veamos sus datos y sus métodos.
Datos Métodos
Coordenada superior izquierda Mostrarse

Coordenada inferior derecha Ocultarse

Tipo de línea Cambiar de posición
Color de la línea
Color del relleno
etc. etc.

Ejemplo 4
Vayamos con otro ejemplo más. Este es para aquellos que ya tienen conocimientos de
informática, y en especial de lenguaje C o Java .
Una clase es un nuevo tipo de dato y un objeto cada una de las asignaciones que hacemos a ese
tipo de dato.

int nEdad = 30;

Hemos creado un objeto que se llama nEdad y pertenece a la clase integer (entero).
Para crear un objeto de la clase marco lo haríamos de forma muy parecida: llamando a la
función creadora de la clase marco:

Marco oCajaMsg := new Marco();

No se preocupe si esto no lo ve claro ahora, esto es algo que veremos con detenimiento más
adelante.

Para crear un objeto de tipo Marco, previamente hemos tenido que crear este nuevo tipo de
dato. Aun cuando ni en Java ni en C un integer sea internamente un objeto, bien podría serlo;
de hecho no hay ninguna diferencia conceptual entre la clase integer y la clase Marco. La
primera es una de las clases que vienen con el lenguaje y la segunda la creamos nosotros.
Pero del mismo modo a como nEdad es una instancia de la clase integer, oCajaMsg es una
instancia de la clase Marco (De hecho, en Java existe la clase Integer, que si es una clase "de
verdad" (tanto a nivel externo como interno) y de la que se instancias objetos de tipo integer.).
Como se ve, básicamente la OOP lo que nos permite es ampliar los tipos de datos con los
que vamos a trabajar: esto que dicho así, resulta tan tan simple, si lo piensa un poco, verá
que es de una potencia nunca vista antes.
Un objeto lo podemos considerar como un array multidimensional, donde se almacenan los
datos de ese objeto (las coordenadas, el color, etc. en el ejemplo del marco) y sus métodos,
que no serían más que punteros a funciones que trabajan con esos datos.

De hecho, y para ser más precisos, en el array de un objeto no se guardan los punteros a los
métodos de ese objeto, sino los punteros a otros arrays donde se hallan estas funciones, para
ahorrar de este modo memoria. También se guardan punteros a las clases superiores si las
hubiese para buscar allí los métodos que no encontremos en la clase a la que el objeto
pertenece: si un método no es hallado en una clase, se supone que debe pertenecer a la
clase padre (clase superior). A esto le llamamos herencia, pero de esto hablaremos
extensamente más adelante.

Ejemplo 5
Como hemos dicho, una clase es un nuevo tipo de dato y objetos son cada una de las asignaciones
que hacemos a ese tipo de dato.

En C un objeto lo podemos considerar como un Struct . Esta estructura albergaría los datos del
objeto, y los punteros a las funciones que formarían el conjunto de sus métodos, más otros
punteros a las clases superiores (padre).

Cada una de las instanciaciones (asignaciones) de variables que hagamos a un Struct,

equivaldrá a crear un nuevo objeto de una clase.

Las clases aparecen en C como Structs muy mejoradas. De hecho, fueron los Structs quienes
sugirieron y dieron lugar a las clases y son sus antecesores informáticos.
Para que entendamos hasta donde llega esta similitud, le informaremos que existe un programa
que recibe un código fuente hecho en C++ (C con OOP) y devuelve otro código fuente
equivalente al anterior, pero en C normal.

Herencia
Esta es la cualidad más importante de un sistema OOP, la que nos dará mayor potencia
y productividad, permitiéndonos ahorrar horas y horas de codificación y de depuración de
errores. Es por ello que me niego a considerar que un lenguaje es OOP si no incluye herencia,
como es el caso de Visual Basic (al menos hasta la versión 5, que es la última que conozco).

Como todos entendemos lo que es la herencia biológica, continuaremos con nuestro ejemplo
taxonómico del que hablábamos en el epígrafe anterior.
La clase león, como comentábamos antes, hereda cualidades -métodos, en lenguaje OOP- de
todas las clases predecesoras -padres, en OOP- y posee métodos propios, diferentes a los del
resto de las clases. Es decir, las clases van especializándose según se avanza en el árbol
taxonómico. Cada vez que creamos una clase heredada de otra (la padre) añadimos métodos
a la clase padre o modificamos alguno de los métodos de la clase padre.
Veamos qué hereda la clase león de sus clases padre:
 Clase Qué hereda
Vertebrados --> Espina dorsal

Mamíferos --> Se alimenta con leche materna

Carnívoros --> Al ser adultos se alimenta de carne

La clase león hereda todos los métodos de las clases padre y añade métodos nuevos que
forman su clase distinguiéndola del resto de las clases: por ejemplo el color de su piel.
Observemos ahora algo crucial que ya apuntábamos antes: dos subclases distintas, que
derivan de una misma clase padre común, pueden heredar los métodos de la clase padre tal y
como estos han sido definidos en ella, o pueden modificar todos o algunos de estos métodos
para adaptarlos a sus necesidades.
En el ejemplo que exponíamos antes, en la clase león la alimentación es carnívora, mientras
que en la clase hombre, se ha modificado éste dato, siendo su alimentación omnívora.

Pongamos ahora un ejemplo algo más informático: supongamos que usted ha construido una
clase que le permite leer números enteros desde teclado con un formato determinado, calcular
su IVA y almacenarlos en un fichero. Si desea poder hacer lo mismo con números reales (para
que admitan decimales), solo deberá crear una nueva subclase para que herede de la clase
padre todos sus métodos y redefinirá solo el método de lectura de teclado. Esta nueva clase
sabe almacenar y mostrar los números con formato porque lo sabe su clase padre.
Las cualidades comunes que comparten distintas clases, pueden y deben agruparse para
formar una clase padre -también llamada superclase-. Por ejemplo, usted podría derivar las
clases presupuesto, albarán y factura de la superclase pedidos, ya que estas clases comparten
características comunes. De este modo, la clase padre poseería los métodos comunes a todas
ellas y sólo tendríamos que añadir aquellos métodos propios de cada una de las subclases,
pudiendo reutilizar el código escrito en la superclase desde cada una de las clases derivadas.
Así, si enseñamos a la clase padre a imprimirse, cada uno de los objetos de las clases
inferiores sabrán automáticamente y sin escribir ni una solo línea más de código imprimirse.

¡Genial! estará pensando usted, desde luego que lo es.

La herencia como puede intuir, es la cualidad más importante de la OOP, ya que le permite
reutilizar todo el código escrito para las superclases re-escribiendo solo aquellas diferencias que
existan entre éstas y las subclases.

Veamos ahora algunos aspectos más técnicos de la herencia:

A la clase heredada se le llama, subclase o clase hija, y a la clase de la que se hereda
superclase o clase padre.
Al heredar, la clase heredada toma directamente el comportamiento de su superclase, pero
puesto que ésta puede derivar de otra, y esta de otra, etc., una clase toma indirectamente el
comportamiento de todas las clases de la rama del árbol de la jerarquía de clases a la que
pertenece.
Se heredan los datos y los métodos, por lo tanto, ambos pueden ser redefinidos en las clases
hijas, aunque lo más común es redefinir métodos y no datos.
Muchas veces las clases –especialmente aquellas que se encuentran próximas a la raíz en el
árbol de la jerarquía de clases– son abstractas, es decir, sólo existen para proporcionar una
base para la creación de clases más específicas, y por lo tanto no puede instanciarse de ellas;
son las clases virtuales.
Una subclase hereda de su superclase sólo aquellos miembros visibles desde la clase hija y por
lo tanto solo puede redefinir estos.
Una subclase tiene forzosamente que redefinir aquellos métodos que han sido definidos como
abstractos en la clase padre o padres.
Normalmente, como hemos comentado, se redefinen los métodos, aun cuando a veces se
hace necesario redefinir datos de las clases superiores. Al redefinir un método queremos o bien
sustituir el funcionamiento del método de la clase padre o bien ampliarlo.

En el primer caso (sustituirlo) no hay ningún problema, ya que a la clase hija la dotamos con un
método de igual nombre que el método que queremos redefinir en la clase padre y lo
implementamos según las necesidades de la clase hija. De este modo cada vez que se invoque
este método de la clase hija se ejecutará su código, y no el código escrito para el método
homónimo de la clase padre.
Pero si lo que queremos es ampliar el funcionamiento de un método existente en la clase padre
(lo que suele ser lo más habitual), entonces primero tiene que ejecutarse el método de la clase
padre, y después el de la clase hija. Pero como los dos métodos tienen el mismo nombre, se
hace necesario habilitar alguna forma de distinguir cuando nos estamos refiriendo a un método
de la clase hija y cuando al del mismo nombre de la clase padre.

Esto se hace mediante el uso de dos palabras reservadas, las cuales pueden variar
dependiendo del lenguaje que se utilice, pero que normalmente son: this (en algunos lenguajes
se utiliza la palabra reservada Self) y super.

this
Con esta palabra, podemos referirnos a los miembros de la clase.
De hecho, siempre que dentro del cuerpo de un método nos refiramos a cualquier miembro de la
clase, ya sea una variable u otro método, podemos anteponer this, aunque en caso de no existir
duplicidad, el compilador asume que nos referimos a un miembro de la clase.
Algunos programadores prefieren utilizar this para dejar claro que se está haciendo referencia a
un miembro de la clase.

super
Al contrario que this, super permite hacer referencia a miembros de la clase padre (o a los
ancestros anteriores, que no hayan sido ocultados por la clase padre) que se hayan redefinido
en la clase hija.

Si un método de una clase hija redefine un miembro –ya sea variable o método– de su clase
padre, es posible hacer referencia al miembro redefinido anteponiendo super .
Veamos un ejemplo (suponemos que solo los datos especificados de la clase A son visibles
desde la clase B):

Clase A

Datos Visible Métodos Visible

AD1 No AM1 No

AD2 Si AM2 Si

AD3 Si Am3 Si

La clase B hereda de la clase A:

Cl ase B
Datos Heredado Métodos Heredado

Datos Visible Métodos Visible

AD2 Si AM2 Si
AD3 Si AM3 Si
BD1 No BM1 No
BD2 No BM2 No

Si en la clase B quisiéramos redefinir el método AM2 de la clase A ampliándolo tendríamos que

referirnos a él mediante súper del Siguiente modo:

public void AM2::B

{
super.AM2(); // Invocamos la ejecución del método AM2::A
 ::B indica que el método AM2 está dentro de la clase B, al igual que AM2::A indica que es
método AM2 de la clase A. Las palabras en azul indican el alcance del método y el valor que
este devuelve (no se preocupe si no lo entiende ahora). En rojo hemos indicado el centro del
tema que estamos tratando.
Veamos otro caso: supongamos que desde el método BD1 (BD1::B) queremos invocar el
método AM2 de la clase B (AM2::B) y que desde el método BD2 (BD2::B) queremos invocar el
método AM2 de la clase A (AM2::A).
public void BD1::B
{
AM2(); // Invocamos la ejecución del método AM2::B
this.AM2() // Lo mismo que la línea anterior, pero usando this
....................... // Resto del la implementación de BD1::B
}

public void BD2::B

{
super.AM2(); // Invocamos la ejecución del método AM2::A

// Resto del la implementación de BD2::B

Encapsulación
Hemos definido antes un objeto como un conjunto de datos y métodos. Dijimos también, que los
métodos son procedimientos que trabajan con los datos del objeto. Veamos esto ahora con más
detenimiento.
Cuando definíamos el concepto de objeto un poco más arriba, dimos varios ejemplos de objetos;
el tercero se refería a un marco (un recuadro) que podía visualizarse en nuestra pantalla de
ordenador. La clase marco tenía las siguientes características:
Datos Métodos
Coordenada superior izquierda Mostrarse
Coordenada inferior derecha Ocultarse

Tipo de línea Cambiar de posición

Color de la línea

Color del relleno

Evidentemente, podríamos (y así deberíamos hacerlo) derivar la clase marco de la superclase

visual, pero para simplificar lo más posible y centrarnos en lo que ahora tratamos, vamos a
considerar esta clase como totalmente independiente de las demás.
Los datos de la clase son siempre los mismos para todos los objetos de esa clase, e igualmente
los métodos, pero para cada instanciación de la clase -cada uno de los objetos pertenecientes a
esa clase- los valores de esos datos serán distintos; los métodos trabajarán con cada uno de
estos valores de los datos dependiendo del objeto del que se trate.
Veámoslo gráficamente, supongamos que la tabla es nuestro monitor en modo texto 80x24 y
los recuadros son dos objetos de la clase marco.

Hemos puesto en cada una de las esquinas las coordenadas de los vértices de los objetos
marco. Estas coordenadas son, desde luego, aproximadas y se las hemos escrito en el
siguiente formato: primero la ordenada y luego la abcisa (<Ypos>,<Xpos>), situando el origen
de coordenadas en el ángulo superior izquierdo de la pantalla con origen en 0,0. De hecho,
para definir un cuadrado en un plano cartesiano solo es necesario definir los dos vértices
superior izquierdo e inferior derecho.
De este modo, podemos apreciar cómo ambos objetos poseen los mismos datos:

Valores
Datos
Obj-1 Obj-2
Coordenada superior izquierda 7, 5 14,50

Coordenada inferior derecha 22,12 20,60

Color de la línea Verde Verde

Tipo de línea del recuadro Doble Simple

Los datos son los mismos, pero los valores que toman esos datos son diferentes para cada
objeto.
Ahora, podemos aplicar los métodos a los datos. Estos métodos producirán distintos resultados
según a qué datos se apliquen. Así, el objeto marco 1, al aplicarle el método Mostrarse,
aparece en la parte izquierda, rectangular verticalmente y con línea doble, mientras que el
objeto marco 2, al aplicarle el mismo método, aparece en la parte izquierda, cuadrado y con
línea simple.
Si quisiéramos ahora aplicarle el método Cambiar de posición al objeto marco 1, este método
debería seguir los siguientes pasos y en este orden.

• Llamar al método Ocultarse para este objeto.

• Cambiar los datos de coordenadas para este objeto.
• Llamar al método Mostrarse para este objeto.

Vemos así cómo un método de una clase puede llamar a otros métodos de su misma clase y
cómo puede cambiar los valores de los datos de su misma clase. De hecho es así como debe
hacerse: los datos de una clase sólo deben ser alterados por los métodos de su clase; y no de
forma directa (que es como cambiamos los valores de las variables de un programa). Esta es
una regla de oro que no debe olvidarse: todos los datos de una clase son privados y se
accede a ellos mediante métodos públicos.
Veamos cómo se realiza esta acción según los dos modos comentados. Tomemos como
ejemplo un objeto perteneciente a la clase marco, modificaremos su dato nY1 (coordenada
superior izquierda) de dos modos distintos: directamente y mediante el método PonerY1().
Cambio directo: oCajaGeneral.nY1 = 12;
Cambio mediante invocación de método: oCajaGeneral.PonerY1( 12 );
Es más cómodo el primer método, ya que hay que escribir menos para cambiar el valor del
dato y además, a la hora de construir la clase, no es necesario crear un método para cambiar
cada uno de los datos del objeto. Sin embargo, y como ya hemos comentado, la OOP
recomienda efusivamente que se utilice el segundo procedimiento. La razón es bien simple:
una clase debe ser una estructura cerrada, no se debe poder acceder a ella si no es a través de
los métodos definidos para ella. Si hacemos nY1 público (para que pueda ser accedido
directamente), estamos violando el principio de encapsulación.
Esta forma de trabajo tiene su razón de ser: en algunos casos, pudiera ser que el método que
cambia un dato realiza ciertas acciones o comprobaciones que el programador que está
usando un objeto creado por otra persona no conoce, con lo que al manipular los datos del
objeto directamente, podemos estar provocando un mal funcionamiento del mismo.
Para evitar que se puedan modificar datos que el usuario del objeto no debe tocar, algunos de
ellos se hacen de solo-lectura, es decir, se puede saber su valor, pero no alterarlo. A estos
datos los llamamos ReadOnly -LecturaSolo-.
Sin embargo, hay una excepción a esta regla: se pueden hacer públicos todos los datos que la
clase no utiliza. Y usted se preguntará, si la clase no los utiliza ¿Para qué los quiere? Hay un
caso especial en el que al usuario de la clase se le proporciona una "bolsa" ("cargo" en Clipper,
"tag" en Delphi) para que él almacene allí lo que quiera. De hecho, este recurso no es muy
ortodoxo, ya que lo que la teoría dice es que hay que heredar de la clase y añadir lo que uno
necesite, pero es un recurso muy práctico, muy cómodo, y tampoco hay que ser más papistas
que el Papa.

Dejemos ahora un poco de lado a los datos para centrarnos en otros aspectos de los métodos.
¿Cómo requerimos la actuación de un método?
Enviando un Mensaje al objeto.
Al enviar un mensaje, se ejecuta un método, el cual puede llamar a su vez a otros métodos de
su clase o de cualquier otra clase o bien cambiar los valores de los datos de ese objeto. Si el
programador tiene que alterar los valores de los datos de un objeto deberá mandar un mensaje
a ese objeto; lo mismo sucede cuando un objeto tiene que cambiar los valores de los datos de
otro objeto.
Como podemos apreciar, un objeto es como una caja negra, a la que se le envía un mensaje y
éste responde ejecutando el método apropiado, el cual producirá las acciones deseadas. un
objeto, una vez programado es solo manipulable a través de mensajes.
A este intrínseco vínculo entre datos y métodos y al modo de acceder y modificar sus datos es
a lo que llamamos Encapsulación . Gracias a la encapsulación, una clase, cuando ha sido
programada y probada hasta comprobar que no tiene fallos, podemos usarla sin miedo a que al
programar otros objetos estos puedan interferir con los primeros produciendo efectos
colaterales indeseables que arruinen nuestro trabajo; esto también nos permite depurar
(eliminar errores de programación) con suma facilidad, ya que si un objeto falla, el error solo
puede estar en esa clase, y no en ninguna otra. Si usted ha programado con técnicas
tradicionales sabrá apreciar lo que esto vale.

Polimorfismo
Por polimorfismo entendemos aquella cualidad que poseen los objetos para responder de
distinto modo ante el mismo mensaje.

Pongamos por ejemplo las clases hombre, vaca y perro, si a todos les damos la orden
-enviamos el mensaje- Come, cada uno de ellos sabe cómo hacerlo y realizará este
comportamiento a su modo.

Veamos otro ejemplo algo más ilustrativo. Tomemos las clases barco, avión y coche, todas
ellas derivadas de la clase padre vehículo; si les enviamos el mensaje Desplázate , cada una
de ellas sabe cómo hacerlo.

Realmente, y para ser exactos, los mensaje no se envían a las clases, sino a todos o algunos
de los objetos instanciados de las clases. Así, por ejemplo, podemos decirle a los objetos Juan
Sebastián el Cano y Kontiqui , de la clase barco que se desplacen, con los que el resto de los
objetos de esa clase permanecerán inmóviles.

Del mismo modo, si tenemos en pantalla cinco recuadros (marcos) y tres textos, podemos
decirle a tres de los recuadros y a dos de los textos que cambien de color y no decírselo a los
demás objetos. Todos estos sabrán cómo hacerlo porque hemos redefinido para cada uno de
ellos su método Pintarse que bien podría estar en la clase padre Visual (conjunto de objetos
que pueden visualizarse en pantalla).
En programación tradicional, debemos crear un nombre distinto para la acción de pintarse, si se
trata de un texto o de un marco; en OOP el mismo nombre nos sirve para todas las clases
creadas si así lo queremos, lo que suele ser habitual. El mismo nombre suele usarse para
realizar acciones similares en clases diferentes.

Si enviamos el mensaje Imprímite a objetos de distintas clases, cada uno se imprimirá como le
corresponda, ya que todos saben cómo hacerlo.

El polimorfismo nos facilita el trabajo , ya que gracias a él, el número de nombres de

métodos que tenemos que recordar disminuye ostensiblemente.
La mayor ventaja la obtendremos en métodos con igual nombre aplicados a las clases que se
encuentran próximas a la raíz del árbol de clases, ya que estos métodos afectarán a todas las
clases que de ellas se deriven.

Sobrecarga
La sobrecarga puede ser considerada como un tipo especial de polimorfismo que casi todos los
lenguajes de OOP incluyen.
Varios métodos (incluidos los "constructores", de los que se hablará más adelante) pueden
tener el mismo nombre siempre y cuando el tipo de parámetros que recibe o el número de ellos
sea diferente.
De este modo, por ejemplo la clase File puede tener tantos método Write() como tipos de datos
queramos escribir (no se preocupe si no entiende la nomenclatura, céntrese en la idea):

File::Write( int i ); Escribe un integer

File::Write( long l ); Escribe un long

File::Write( float f ); Escribe un flota

File::Write( string s ); Escribe una cadena

File::Write( string s, boolean b ); Escribe una cadena pasándola

a mayúsculas

Existe un tipo especial de sobrecarga llamada sobrecarga de operadores que, de los leguajes
OOP conocidos, solo incorpora C++. Es por esto que consideramos que el abordar este tema
escapa a la finalidad del presente curso.
 PROGRAMACIÓN ORIENTADA A OBJETOS

– ¿Qué es POO?
Hace tiempo había prometido a mis alumnos de ActionScript que les daría algunos apuntes
acerca de la Programación Orientada a Objetos y cómo aplicarla en AS2. Pues bien, el
momento de cumplir esa promesa ha llegado; para ello voy a darme a la tarea de estructurar
una serie de posts al respecto, tratando de comprender lo que significa la Programación
Orientada a Objetos y como aplicarla en AS2 dirigida a no-programadores (que son la mayoría
de mis alumnos). La idea que tengo en mente es estructurar un material que permita entrar en
el fascinante mundo de la Programación, principalmente pero no limitándonos a AS2, para
luego hacer un paso seguro y firme a AS3 y ver también como podemos aplicar esto en otros
lenguajes sumamente útiles en el desarrollo web, como PHP y Javascript.

¿Qué es la Programación Orientada a Objetos?

La P.O.O. (también conocida como O.O.P., por sus siglas en inglés) es lo que se conoce como
un paradigma o modelo de programación. Esto significa que no es un lenguaje específico, o
una tecnología, sino una forma de programar, una manera de plantearse la programación. No
es la única (o necesariamente mejor o peor que otras), pero se ha constituido en una de las
formas de programar más populares e incluso muchos de los lenguajes que usamos hoy día lo
soportan o están diseñados bajo ese modelo (PHP, AS2, AS3,…).

Lo que caracteriza a la POO es que intenta llevar al mundo del código lo mismo que
encontramos en El Mundo Real™. Cuando miramos a nuestro alrededor ¿qué vemos? pues,
cosas, objetos, pero podemos reconocer estos objetos porque cada objeto pertenece a una
clase, eso nos permite distinguir, por ejemplo, un perro de un auto (porque son de clases
diferentes) y también un TV de otro (porque, aunque sean iguales, cada uno es un objeto
distinto). Éste es el modelo que la POO intenta seguir para estructurar un sistema.

Es importante recalcar nuevamente que la POO no es un lenguaje de programación, es una

forma de enfrentarse a ella. Esto significa que la POO le servirá para desarrollar en muchos de
los lenguajes comunes de hoy en día (incluso en ASP) manteniendo un mismo esquema
mental. Incluso le permitirá enfrentar otros proyectos que no necesariamente estén
relacionados con escribir código…

CARACTERÍSTICAS DE LA P.O.O
No hay un acuerdo aceptado por todo el mundo respecto a cuáles son las características que
definen la POO, pero al menos todos concuerdan en estas tres:

• Abstracción.
• Encapsulación.
• Herencia.
Abstracción:
Cada vez que pronunciamos una palabra, realmente lo que hacemos es asociar ese sonido (o
ese conjunto de garabatos al escribir) con una serie de cosas. Decimos que una ave es tal
cosa, que una silla es tal otra, etc.

Cuando vamos a aplicar la POO, lo primero que debemos hacer es cumplir con una vieja
máxima de guerra: Divide y Vencerás. Es decir, lo que hacemos es seccionar nuestro código
en grupos de código más pequeño que, al unirlos, hacen el trabajo. Un buen ejemplo de
abstracción es el cuerpo humano, aunque el cuerpo es una unidad, está dividido en lo que
conocemos por sistemas (el sistema respiratorio, el sistema linfático, cardiovascular, etc., etc.).
Estos sistemas, a su vez están compuestos por otros más pequeños: los órganos, y así
sucesivamente. La abstracción nos permite dividir nuestro programa en distintos objetos que se
agrupan para formar cosas más complejas.

Pero ¿qué demonios es realmente la abstracción? Básicamente es la capacidad de separar los

elementos (al menos mentalmente) para poder verlos de forma singular. Como cuando
describimos el cuerpo humano y decimos cabeza, brazo(s), pierna(s), etc.

Encapsulación:
También conocida como ocultamiento. Cuando me acuesto a ver televisión no me preocupo
del modo como éste funciona, o lo que hace para cambiar de canal o aumentar el volumen. A
menos que seas experto en electrónica o técnico en televisores, te pasará lo mismo: no lo
sabes y no te importa; sólo sabes que al presionar un botón ocurre la magia.

La encapsulación se encarga de mantener ocultos los procesos internos que necesita para
hacer lo que sea que haga, dándole al programador acceso sólo a lo que necesita. Esto da
dos ventajas iniciales: Lo que hace el usuario puede ser controlado internamente (incluso sus
errores), evitando que todo colapse por una intervención indeseada (tú no quieres que tu
mamá, que no tiene ni idea de electrónica, abra tu televisor y empiece a jugar con los circuitos
para cambiar los canales manualmente ¿verdad?). La segunda ventaja es que, al hacer que la
mayor parte del código esté oculto, puedes hacer cambios y/o mejoras sin que eso afecte el
modo como los usuarios van a utilizar tu código. Sólo tienes que mantener igual la forma de
acceder a él (en el caso del control de la tele, que los botones sigan siendo los mismos y que el
botón de “apagado” no cambie el volumen). Por cierto, estas puertas de acceso que das a los
usuarios son lo que se conoce como interfaz.

Herencia:

Uno de los elementos (a mi modo de ver) más interesantes de la P.O.O. La herencia es la

capacidad que tiene una clase de derivar las propiedades y métodos de otra. Tratemos de
explicarlo con un ejemplo:

Decimos que una gallina es un ave; esto quiere decir que las gallinas tienen características
comunes con otras aves (pico, plumas, etc.), es decir que la gallina hereda las características
comunes de todas las aves. Pero además, resulta que un ave es un animal, lo que significa
que también comparte características comunes al caballo, el perro, el hombre (seeee, somos
animales) y cualquier otra cosa que pueda ser clasificada como animal.

La herencia nos permite, entre otras cosas, evitar tener que escribir el mismo código una y otra
vez, puesto que al definir que una categoría (que en programación llamaremos clase)
pertenece a otra, automáticamente estamos atribuyéndoles las características generales de la
primera, sin tener que definirlas de nuevo.

¿Qué es una Clase?

Cuando decimos “ave”, sabemos que nos referimos a “algo” con plumas, pico, dos patas, etc.
No importa realmente si hemos visto un ave o no, o si tenemos un ave frente a nosotros;
entendemos claramente que la palabra “ave” se refiere a alguna cosa que cumple con unas
características específicas, se comporta de una forma concreta, etc. No es más que una
palabra, pero nos permite clasificar las cosas. Por ejemplo, sabemos que una gallina es un ave
y que un perro no es un ave.

La clasificación es algo que hacemos todos los días, a cada momento (entre otras cosas, nos
libra de utilizar medias como guantes o bañarnos en el comedor en vez de en la ducha). Cada
vez que decimos que algo es alguna cosa, estamos clasificándolo, asociándolo a una clase.

Sin embargo, sabemos que la palabra ave no se refiere a un animal concreto, sino a una serie
de animales. Ave es la palabra que usamos para identificarlos en un grupo, pero no podemos
decir hoy haré volar la palabra “ave” (bueno, puedes decirlo, pero estarás cada vez más cerca
del manicomio), en tal caso siempre nos referiremos a esta o aquella ave, siempre hablaremos
de un animal concreto. La palabra es lo que conocemos como un concepto, una abstracción.

En la POO ocurre igual, una clase no es más que una serie de código que define a todos los
elementos relacionados con ella. Así, podríamos escribir la clase ave colocando en ella todas
las características que tienen las aves (pico, color, alto, ancho, patas,…) esas características
las llamaremos en lenguaje de programadores, propiedades.

Pero la cosa no termina allí, resulta que las aves tienen también ciertos mecanismos
específicos, como comer, dormir, reproducirse, etc. Estos mecanismos los llamamos
métodos.

Por último, también sabemos que las aves reaccionan ante ciertos sucesos, como peligro,
atracción, defensa… A esto lo llamaremos eventos.

Entonces, vemos que una clase es algo así como el concepto de lo que queremos hacer, es
como la idea (concebida al detalle) de la cosa, del objeto; pero igual que con las ideas, no
puedo hacer nada directamente con una clase (puedes sentarte en una silla, pero no en tu idea
de una silla). Sin embargo, esta idea será la que dé forma al objeto que crearemos (que tendrá
las características, mecanismos y comportamientos que habíamos pensado en nuestra idea).
¿Qué es una Instancia?
Bien, decíamos que una clase es como la definición de un objeto, pero no es el objeto en sí, del
modo como una idea no es una cosa física (el ejemplo de la silla). Así que para sentarnos
necesitaremos convertir esa idea en algo, en un objeto real; a ese objeto lo llamamos
instancia.

En un mismo proyecto puedo tener una o más instancias de una misma clase sin problemas.

Cada vez que creamos una nueva instancia, ésta adquiere las propiedades, métodos y eventos
de la clase a la que pertenece (es lo que permite la relación es un), sin embargo, cada
instancia es independiente de las otras; esto nos da dos ventajas:

1. Si hago algún cambio en la clase, todas las instancias de esta clase se actualizarán
automáticamente; esto nos permite hacer cambios sin tener que ir a cada una de las
instancias (se aplica el mismo principio de herencia, aunque a un nivel diferente).
2. Al ser independientes de las otras instancias, puedo darles valores diferentes sin que
afecten a las demás (como tener una silla negra, una roja, una más alta, etc.). Aunque
comparten la misma estructura, pueden programarse individualmente, dando
versatilidad y flexibilidad al código.
Cómo Escribir una Clase
Ahora que entendemos (más o menos) cómo funciona la teoría básica de la P.O.O. y sabemos
acerca de la importancia de las clases, es momento para que veamos cómo sería la estructura
de una clase.

Es importante tener en cuenta que cada lenguaje tiene, de acuerdo a su sintaxis, sus propias
normas sobre cómo escribir clases. No será lo mismo en PHP que en AS2 o incluso AS3. Así
que, primero, hablaremos en un sentido más general, para luego pasar a la práctica concreta.
Para los efectos, usaremos como lenguaje de ejemplo Action Script 2.0.

Estructura de la Clase
Los elementos básicos de una clase se estructuran de la siguiente forma (más abajo
definiremos cada elemento):

1. Paquete al que pertenece la clase (package – sólo en AS3, en AS2 se incluye en la

Definición de la Clase).
2. Definición de la Clase (class – En AS2, si la clase está incluida en un paquete, se usa
la sintaxis paquete.clase).
3. Variables Internas (Son de uso interno de la clase, por lo que se restringe su uso fuera
de ellas con la palabra clave private, así la variable miVar, de tipo numérico, podría
definirse así:

private var miVar:Number = 0;)

4. Constructor de la Clase (excepto en el caso de las clases estáticas, pero de eso

hablaremos en otro post).
5. Propiedades, Métodos y Eventos de la Clase (no necesariamente en ese orden, pero
es una buena forma de organizarlo).

Por supuesto, una clase bien hecha contiene además comentarios con información sobre la
clase, la forma de usarla, su autor, etc. En este caso lo omitimos para concentrarnos en lo
básico y no enredarnos más de lo estrictamente necesario.

Dicho esto, veamos los puntos nombrados arriba en una clase de ejemplo, para luego pasar a
explicar los conceptos:
Para crear una nueva instancia de la clase Persona debemos importarla y luego instanciar con
la palabra clave new, pasándole los parámetros que necesita:

import cesarfrick.Persona;
var cesar:Persona = new Persona("César", "Frick", 36);

Ahora expliquemos de qué se trata lo que hemos dicho:

Paquete:
Aunque podemos colocar nuestras clases en el mismo directorio donde se encuentra el
archivo que los usará, siempre resulta más ordenado y eficiente clasificarlos en
carpetas, donde podemos colocar aquellas clases que tienen un mismo propósito. Así
 podemos tener una carpeta llamada graph para clases de tipo gráfico, externalData
para clases que conectan y/o procesan datos externos, etc. Estas carpetas son
conocidas como paquetes.
Otra ventaja de usar paquetes (además de mantener nuestras clases ordenadas) es
que nos permiten importar todas las clases que necesitemos de ellos con sólo una
línea: import paquete.*, en vez de tener que hacer un import para cada clase. Si te
preocupa que terminen importándose más clases de las que necesitas de ese paquete,
no hay problema porque sólo se importarán las que sean necesarias y no las que no
utilices en el código.
En algunos lenguajes, existen palabras reservadas para declarar el paquete al que
pertenece una clase (como en el caso de AS3), en estos casos va primero la
declaración del paquete y luego la de la clase. En AS3 sería de esta forma:

package nombreDelPaquete{
class NombreDeLaClase{
...
}
}

Clase:
La clase, propiamente dicha, se declara con la palabra clave class.

Hay un par de cosas que debemos tener en cuenta cuando creamos una clase:

• No es obligatorio, pero por regla general -los entendidos lo llaman convención y es

cuando todos se ponen de acuerdo en hacer algo de la misma forma (¡ja! como si tal
cosa fuese posible. Errr… perdón, eso es otro tema)- los nombres de las clases siempre
comienzan con mayúsculas.
• Esto si es obligatorio: El archivo donde se encuentra la clase debe tener el mismo
nombre que ésta, respetando mayúsculas y minúsculas. Esto es importante porque los
import usan el nombre del paquete (si lo hubiere) y la clase para ubicarlos en el disco,
así que si usas diferentes nombres, nunca los hallará y dará error.
• Si el lenguaje no tiene una palabra reservada para definir el paquete (AS2, por
ejemplo), la definición de la clase sería así:

class nombreDelPaquete.NombreDeLaClase{
...
}

Variables Internas o Privadas:

En último término, todas las propiedades de una clase son en realidad variables, pero
no es conveniente que el usuario de la clase pueda manipular directamente estas
variables, por ello se mantienen privadas, es decir, sólo pueden llamarse y
manipularse dentro del código de la clase, pero no fuera de ellas (o sea que si se
trata de llamar a una de estas variables desde la instancia, no funcionará). Para hacer
que una variable/función sea privada, se le antepone la palabra private.

Constructor:
Es la función que se ejecuta cada vez que se crea una instancia de la clase, Si
necesitamos que nuestra clase inicie con ciertos valores, colocamos los parámetros
correspondientes entre los paréntesis. La función constructora siempre devuelve Void
(Vacío).
 También puede haber casos en los que no queramos que la clase constructora ejecute
ningún código. Para ello simplemente la colocamos vacía, es decir, la declaramos pero
no ponemos código en ella. Si una clase no tiene un constructor, no puede ser
instanciada.

Propiedades, Métodos y Eventos de la clase:

Decíamos antes que las propiedades son realmente variables dentro de la clase, pero
para poder controlar qué puede cambiar o no el usuario de la clase, si los valores son
correctos, etc. hacemos uso de unas funciones especiales para definir propiedades: get
y set.
• get permite al usuario recuperar el valor de la propiedad, leerlo, por lo
que su salida debe ser correspondiente con la que se espera de la propiedad
(por ejemplo, no tendría sentido que la propiedad “nombre” del ejemplo
devolviese un número). Si sólo creamos una función get para una propiedad,
ésta es de sólo lectura.
• set es usado para darle un valor a la propiedad, normalmente se añaden
aquí los controles para asegurarse que el valor que se asigna es del tipo
deseado (y evitar que la clase colapse por un error de tipo de datos). La función
de set, al ser para escribir en la propiedad no devuelve ningún tipo de datos,
pero debe tener un parámetro que es el valor que se pasará a la variable. Al
contrario de get, no puede haber una clase de sólo escritura (después de todo,
no tiene ningún sentido tener una propiedad a la que se le pueda asignar un
valor pero este no pueda ser recuperado).
• Los métodos no son más que funciones públicas, que pueden tener o no
datos y que afectan a la instancia de alguna forma.
• Los eventos, al igual que los métodos, son funciones, pero estos
reaccionan ante alguna interacción del usuario o pueden ser reescritos por éste.
A ellos dedicaremos un post especial.

Bien, escribir una clase no es tan complicado como puede pensarse en un principio. A
continuación hablaremos de las ventajas/desventajas de usar clases, pero por ahora creo que
ha sido bastante (al menos yo estoy exhausto). Sólo decir que si les resulta muy complicado lo
que ven acá, repasen los posts anteriores (seee, he tardado mucho en escribir éste) para que
lo vean en contexto. También decir que en este caso y todos los que vengan escribiremos el
código siguiendo las reglas del Strict Data Typing (Tipeo Estricto de Datos), al que le daremos
unas líneas en el próximo post.

Ámbito, Public, Private, Protected, Local

Bien, los temas que vamos a tratar en esta ocasión son tan básicos que posiblemente alguno
piense ¿y por qué no hablamos de esto al principio? Y la respuesta lógica es: porque no lo
habríamos entendido correctamente.
El tema que vamos a tratar ahora es uno de los mayores dolores de cabeza cuando se
comienza con la programación -y más aún con la programación orientada a objetos-, muchos
problemas en el código suelen estar asociados con algún error a nivel de ámbito, así que
comencemos por allí:
¿Qué es el Ámbito y Cómo Afecta mi Vida Sexual?
Cuando hablamos de ámbito o alcance nos estamos refiriendo principalmente al área de
influencia de una variable o función, a la zona donde ésta tiene sentido.

Toda variable/función tiene un rango de acción, se encuentra en un sitio, tiene un contexto,

fuera del cual pierde significado y valor. Un ejemplo que puede ilustrar esto puede ser un
lámpara. La lámpara, al encenderla, ilumina un área específica, pero no tiene influencia fuera
de esa área. Por ejemplo: si necesito buscar algo en mi cuarto, que la luz de la sala o de la
cocina estén encendidas sería irrelevante para mí porque mi cuarto está fuera del área que
ellas iluminan, pero si enciendo la luz de mi cuarto puedo buscar lo que necesito más
claramente, aunque no tendría ninguna influencia fuera de él, él ámbito (alcance) de esa luz se
limita a mi cuarto.

De acuerdo con su ámbito una variable/función puede ser:

• Pública - Public
• Privada - Private
• Protegida - Protected
• Local - Local

Vamos a hablar de estos ámbitos desde el punto de vista de la clase.

Public:
Una variable/función pública puede ser accedida desde fuera de la clase. Es decir, puedo
acceder desde la instancia de la clase y no sólo desde el código interno de la clase. Ejemplo de
funciones públicas son los métodos de una clase. También es posible crear variables públicas,
para que puedan ser manejadas desde la instancia, pero no es algo común o recomendable,
entre otras cosas porque deja un hueco de seguridad en la clase, acabando con la idea de la
“encapsulación”. Para declarar una variable/función como pública, se le antepone la palabra
clave “public”.

Private:
Al contrario que las públicas, las variables/funciones privadas sólo pueden ser accedidas desde
dentro de la misma clase. Todo intento de llamarlas desde la una instancia de la misma es en
vano. Mantener variables/funciones privadas permiten tener un mayor control sobre la clase,
sobre el modo como procesa sus métodos, como maneja sus variables, etc. Para declarar una
variable/función como privada, se le antepone la palabra clave “private”.

Protected:
Existe un tipo intermedio de ámbito, llamado “protegido”. Es un punto medio entre público y
privado, porque -como ocurre con las privadas- no se puede acceder a ella desde una instancia
de la clase, pero -como ocurre con las públicas- puede ser accedido desde las subclases de
ésta, no importa si se encuentran o no en el mismo paquete. Básicamente significa que, si una
clase hereda de otra, tendrá acceso a las variables/funciones protegidas de la super-clase, de
lo contrario, no podrá acceder a ellas. Para declarar una variable como protegida, se le
antepone la palabra clave “protected”.
Local:
Una variable “local” sólo es accesible desde dentro de la función donde se declara; esto es
válido tanto para los parámetros de la función como para las variables declaradas dentro de
ella. Una vez terminada la función, la variable es destruida hasta que la función vuelve a ser
invocada. No hay palabras clave para las variables locales.

¿Cómo Afecta esto mi Vida Sexual?

Como dije, una buena parte de los problemas que la gente suele tener al trabajar con clases es
comprender cómo funcionan los ámbitos, cómo acceder a funciones/propiedades/variables y
como permitir a otros que accedan a las nuestras; por lo tanto, entender esto significa perder
menos horas depurando código, lo que significa menos tiempo programando, lo que es igual a
menos frustración por falta de tiempo para el sexo.

Clases Dinámicas y Clases Estáticas

Bien, hemos llegado lejos -al menos más lejos de lo que pensé en un principio- y hasta ahora
hemos establecido las bases para entender de qué se trata todo esto de la Programación
Orientada a Objetos y cómo escribir y usar nuestras clases. Lo que haremos a partir de este
punto será concentrarnos más en ciertos detalles relativos a la creación y utilización de las
clases, que nos permita que nuestros proyectos sean más eficientes y flexibles para, entre
otras cosas, no vernos en la necesidad de tener que modificar una clase cada vez que vamos a
usarla en un nuevo proyecto (algo que es muy común cuando se comienza a programar con
ellas) y hallar la forma de tener un mejor control de nuestro código sin que ello sea un dolor de
cabeza a la hora de usarlas en distintos proyectos.

En este post nos concentraremos en averiguar cuáles son los tipos de clases que existen y
cuál es la utilidad de cada uno. Por eso, antes de comenzar, quiero hacer una aclaratoria para
no confundirnos a causa del título. Existen tres tipos básicos de clases: cerradas, dinámicas y
estáticas.
La razón por la que no hablaremos del primer tipo es porque ya lo conocemos (O’ RLY?). Sí,
las clases que hemos estado programando hasta ahora se conocen como clases cerradas, es
decir, todos los eventos, métodos y propiedades están definidas dentro de la clase, así que no
es posible agregárselos dinámicamente.

Clases Dinámicas
En oposición a las clases cerradas existe lo que se conoce como clases dinámicas. Su
principal característica es que permiten agregar en tiempo de ejecución, propiedades y
métodos a la clase, es decir, que yo puedo agregar una nueva propiedad a la instancia de mi
clase, aunque ésta no haya sido definida originalmente. Veámoslo con un ejemplo comparativo:
Como puedes ver, la única diferencia entre Persona y Persona2 es que en el segundo caso
hemos agregado, en la declaración de la clase, la palabra clave dynamic. Esta palabrita es la
que hará toda la magia, ya que, como puedes ver en la implementación (más abajo, en la
imagen), la instancia de Persona nos dará un error en tiempo de compilación (diciéndonos que
la clase Persona no tiene una propiedad llamada apellido), mientras que Persona2
simplemente creará la nueva propiedad (fíjate que no existe en la clase) y le colocará el valor
correspondiente.

De hecho, si has trabajado con AS2 (que supongo que así es), posiblemente esto sea algo que
has implementado varias veces.

En cualquier caso, no es recomendable usar clases dinámicas a menos que sea necesario,
porque entre otras cosas, la verificación de datos es menos estricta que en las clases cerradas,
lo que hace que se pierda control sobre los datos de la clase, haciéndola susceptible de errores
inesperados.
Clases Estáticas
Por su parte, las clases estáticas están pensadas para contener elementos (propiedades o
métodos) que no dependen directamente de un objeto para su funcionamiento ¿Cómo es eso?
Veamos:

En varias ocasiones nos encontramos con que tenemos una función que
puede ser utilizada por distintos objetos, o en diferentes situaciones, que
no están relacionadas con algún objeto específico, puede ser el caso de
una operación matemática, un cálculo, dibujar una forma geométrica, etc.
Sin las clases estáticas la opción sería: Crear esta misma función en cada
clase que utilizamos (copiar y pegar no es reusabilidad). Pero esto es algo
engorroso y poco práctico (¿qué pasa si queremos agregar un nuevo
parámetro a nuestra función o conseguimos una forma más efectiva de
hacer lo mismo? Tendríamos que reescribir el código en cada clase donde
lo hemos usado… y tú no quieres hacer eso ¿verdad?).

Un buen ejemplo de clases estáticas es la clase Math, común en ActionScript, Java, .Net, etc.
Esta clase se encarga de hacer una serie de operaciones matemáticas a las que sólo les
pasamos los parámetros que necesita. Otro ejemplo típico sería una clase que se encargara de
dibujar objetos. Es la que veremos en este ejemplo:
En este caso, tenemos una clase que contiene un sólo método (getSolidRectangle), que
además es de tipo estático (lo sabemos por el uso de la palabra clave static en la declaración
del método) y que dibuja un rectángulo con color de fondo sólido en un mc que hemos enviado
como primer parámetro.

Si nos fijamos en la implementación de la clase, veremos que sólo tiene tres líneas:

• Importa la clase.
• Crea el movieclip donde dibujaremos el rectángulo.
• Llamamos al método getSolidRectangle para dibujar el rectángulo en cuestión

Como te habrás dado cuenta, en este caso no hemos creado una instancia de Graph (que lo
haríamos con la palabra clave new). Esto se debe a que las clases estáticas no se instancian
(o sea, que no podemos crear objetos a partir de ellas), sino que podemos usar directamente
sus elementos, simplemente apuntando a al clase misma (Graph.getSolidRectangle()). Si
alguna vez has usado la clase Math sabes de lo que estoy hablando.

Es por eso que las clases estáticas normalmente son utilizadas para albergar esos
procedimientos que queremos reutilizar una y otra vez, pero que no están directamente
asociados a un objeto o una clase en particular. Así, en vez de tener que escribir una y otra vez
el mismo procedimiento, sólo tenemos que importar la clase y usarla. Si luego queremos hacer
cambios en el(los) procedimiento(s), hacemos los cambios en la clase estática y estos se
actualizarán automáticamente en todos los sitios donde se utilice. Esto sí es reusabilidad.

Un dato importante, cuando creamos una clase estática, todos los elementos públicos de dicha
clase también deben ser estáticos.

Sub Clases
La herencia es la capacidad que tiene una clase de derivar las propiedades y métodos de otra.

Dicho de otra forma. La herencia se asegura de que una clase, al derivar de otra, tenga las
mismas cualidades de la clase de la que proviene, además de las que sean propias de la
misma clase.

Ocurre lo mismo que con los seres vivos, los animales heredamos de nuestros padres
características como tipo, color de piel, capacidades para desarrollar ciertas destrezas, etc. Sin
embargo, también tenemos cualidades que nos son propias y que nuestros padres no poseen,
como la propia identidad, los gustos propios, etc.

En la POO, una clase que deriva de otra es conocida como sub-clase, y aquella de la que
proviene se conoce como super-clase. Viéndolo de un modo gráfico, sería algo como esto:
En principio, tenemos una super clase llamada Animal, que contiene todos los elementos
generales que tiene todo animal (como alimentación, piel, reproducción, etc.). De esta super-
clase, se derivan toda una serie de clases, que corresponden a los distintos tipos de animales
que existen. Todos ellos tienen una conexión directa de la clase Animal, puesto que provienen
de ella, son sub-clases de Animal.

Sin embargo, hay dos cosas que debemos tener en cuenta: 1. No todas comparten las mismas
características de la clase animal (así Hombre tiene boca, The Parrot™ tiene pico, mientras
Perro y Gato tienen hocico). 2. A pesar de que tienen relación indirecta (porque todas
pertenecen a la misma super-clase), eso no implica que deba haber una relación directa entre
las sub-clases. Es lo mismo que ocurre con nuestros padres y hermanos.

Super Clase y Sub Clase:

Una cosa que debemos tener clara a la hora de meternos en las lides de la herencia es que no
existe propiamente un tipo de clase llamado sub-clase o super-clase. Estos conceptos se
utilizan para definir la relación que existe entre dos clases concretas. Una sub-clase es
simplemente la que hereda de otra clase, a la que llamaremos super-clase; dicho de otro modo,
la super-clase es la clase madre y la sub clase la clase hija. Igual como ocurre en el resto de
las relaciones, nuestra sub-clase puede ser al mismo tiempo una super-clase para otras clases,
y así sucesivamente. Esto es algo que veremos muy comúnmente en la POO donde, por
ejemplo, todas las clases derivan, en algún punto de la clase Object.

¿Para qué Sirven las Sub-Clases?

Si no ha quedado claro hasta ahora, vamos a repetirlo de modo sencillo y directo. Crear sub-
clases nos permite crear una nueva clase personalizada, tomando los elementos que
necesitamos de una clase ya creada. De este modo, no tenemos que volver a escribir todas
las propiedades, métodos y eventos que ya tiene la clase que hemos tomado como base, sino
que podemos utilizarlos directamente, reinterpretarlos o incluso ocultarlos para que no puedan
ser accedidos desde afuera de la clase.
Por ejemplo, quizá te interese que pueda cambiarse la altura de la instancia, pero no quieres
que pueda cambiarse el ancho, aunque un uso más común es darle a nuestra nueva clase
ciertas características que no existen en la super-clase, manteniendo las que ya tenemos en
ella, o también para hacer ciertos cambios en la super-clase. Es lo que se conoce como
extender una clase y es por ello que la palabra para crear una sub-clase es extends.

Wow! esto ha sido largo. Así que dejaremos hasta acá esta parte y en el siguiente post
hablaremos de cómo crear una sub-clase y otras cosas importantes como sobre-escritura de
métodos y cómo acceder a la super clase desde una sub-clase.