Revista Acta Académica Universidad Autónoma de Centro América

Resumen

Introducción

      El reto principal que encaramos los programadores es lograr que los grandes adelantos en electrónica se traduzcan en programas cada vez mejores. Pero no hemos tenido todo el éxito deseado, pues cada vez es más caro contratar a un programador, mientras que es más barato comprar equipo: nuestro "fracaso" existe porque comparamos nuestros avances con los de manufactura de computadores.

      Si han surgido un millar de lenguajes de programación, cabe preguntarse: ¿Qué es lo malo de los primeros 999? ¿Qué motivó el gran uso de DBase? Si hay una gran cantidad de técnicas de programación, ¿cuál de todas debemos usar? ¿Qué perdemos si no las usamos? La respuesta a estas pregunts es complicada, y depende mucho del problema que uno deba resolver por medio de un programa. Para encontrarla es necesario estudiar las necesidades que cada uno de estos nuevos lenguajes ha venido a llenar.

Cronología de los lenguajes de programación

      Al principio no había nada. IBM, en sus primero años, creó el primer Sistema de Programación Automática, que llamó Ensamblador. Entonces los programadores ya podíamos hablar de instrucciones de máquina:
      MOV ax, bp
en lugar de secuencias binarias de programación:
      10001001111000110010011011000110110011100001

      Después de un tiempo surgió el ahora casi obsoleto lenguaje Fortran (FORmula TRANslator, o traductor de fórmulas). Los computadores al principio eran tan caros que sólo los militares los podían pagar, por lo que las primeras aplicaciones computacionales fueron el cálculo numérico de complejas ecuaciones (posiblemente para predecir el lugar en donde debía caer la bomba).

10 REM FACTURACION
20 LET precio = costo + ganancia
30 LET precio = precio * (1 + impuesto/100)
40 GOSUB 300; REM incremente total facturado
50 GOSUB 150; REM imprime factura
60 GOTO 10

      Cuando surgieron los computadores que permitían la programación interactiva nació BASIC, y con él los números de línea, como se muestra en la Figura 1. Con BASIC pudimos escribir el programa más pequeño que se reproduce a si mismo, pues ocupa sólo un byte:
      10 LIST

      La década de los sesenta, produjo lenguajes como Pascal, Algol y PL/I, que difieren de BASIC en que permiten el uso de argumentos, variables locales y programación estructurada. Pascal llena muy bien el paradigma de la programación estructurada, por lo que se ha usado mucho, principalmente en Universidades.

      Conforme aumentó la capacidad de cómputo de los computadores, y se redujo su costo, surgieron nuevos lenguajes que permitían aplicar la computación a nuevos campos. Así nacen una gran cantidad de nuevos desafíos tecnológicos, muchos de los cuales todavía no han sido adecuadamente resueltos. Las últimas tres modas en la tecnología de programación, Programación Lógica, Lenguajes de Cuarta Generación (4GLs) y Programación Orientada a Objetos, son respuesta a estas nuevas aplicaciones.

      Necesariamente las nuevas tecnologías son producto de las viejas. Las ideas que dieron vida a Pascal no pudieron haber existido sin COBOL; para entender una nueva herramienta es importante entender cómo fue creada. Además, el uso de nuevas herramientas rápidamente lleva a detectar sus defectos. Por eso en el nuevo lenguaje se trata de arreglar los defectos de sus antecesores.

Lenguajes de Cuarta Generación

      El lenguaje COBOL representa un avance tecnológico muy importante. Por mucho tiempo la mayor área de aplicación de las computadoras ha estado en los ambientes de negocios, en el proceso de datos relevantes a actividades administrativas. Por eso nació COBOL y tuvo una gran aceptación en las máquinas grandes ("mainframes"). Todavía se usa en muchas instalaciones, aunque es ya bien sabido que COBOL es un lenguaje anacrónico.

      En COBOL hay que escribir mucho código para programar: en COBOL uno no dice leche, dice "líquido perlático de la consorte del toro, pero de la que estuvo recientemente preñada". Este defecto del COBOL indujo a muchas casas productoras de programas a crear herramientas que permitieran programar con más comodidad.

      Con el desarrollo de la tecnología de bases de datos fue posible identificar los siguientes componentes principales de los programas en Sistema de Información:

• Diálogos por pantalla y controles de acceso
• Manipulación de archivos y bases de datos
• Reportes

      Los 4GLs vienen a solventar el problema de expresividad de COBOL, y luego se convierten en herramientas para programar cada uno de los componentes arriba mencionados. Por eso los primeros 4GLs eran generadores de código COBOL, y los modernos son ambientes interactivos de desarrollo de sistemas, cargados de editores muy especializados. Lo común a todos los 4GLs es que minimizan la cantidad de código que hay que escribir para obtener un Sistema de Información.

      Aunque al principio los 4GLs tenían algunas restricciones muy severas, los actuales son una respuesta satisfactoria para programar Sistemas de Información. Permiten ensamblar aplicaciones involucrando bastante al futuro usuario del sistema, y consumen relativamente pocos recursos.

      La parsimonia del 4GL ha permitido también crear sistemas usando prototipos. Un prototipo es un esqueleto, que luego un programador hábil toma y completa con código. De esta manera el analista, en lugar de hablar o de escribir especificaciones, se sienta con su usuario ante una pantalla, y comienza a construir, junto a él, el Sistema de Información. La gran ventaja del uso de prototipos es que el usuario puede participar (y quejarse) en las primeras etapas del diseño del sistema, con lo que se abarata mucho el costo total del sistema.

Tipos de programas

      Si bien es cierto que los Sistemas de Información son la más importante aplicación de las computadoras, estas máquinas también se usan en muchos otros campos. Por ejemplo, existen computadores dedicados a mantener vivos a pacientes que sufren del corazón, hay máquinas dedicadas al control del tráfico aéreo o el control de procesos industriales, o programas para crear otros programas, como los compiladores. Aunque hemos definido claramente los componentes de los Sistemas de Información, no hemos hecho lo mismo para las demás aplicaciones del computador.

      Esto quiere decir que el paradigma para la construcción de Sistemas de Información cristalizado en los 4GLs no es directamente aplicable cuando se implementan otros tipos de programas. Un ejemplo lo es el procesador de palabras que nos hemos acostumbrado a usar todos los días, pues tiene una estructura muy diferente a la de cualquier Sistema de Información, y además usa estructuras de datos y algoritmos (o trucos de programación) muy sofisticados. Es por esto que aunque el 4GL es la herramienta adecuada para una aplicación muy específica, que es la construcción de Sistemas de Información, ha sido necesario desarrollar otras herramientas de programación para las demás aplicaciones. Por eso nació la Programación por Objetos.

Modularidad

      Como los que hacemos computación somos Ingenieros, hemos tratado de encontrar soluciones de programación en la Ingeniería: para esto creamos la Ingeniería de Sistemas. Los programadores tenemos un gran complejo de inferioridad debido al resonante éxito que ha tenido la Ingeniería Electrónica, el que se refleja en el estribillo que se repite en muchos artículos de computadores: "Como el poder de los componentes se ha multiplicado en órdenes de magnitud...". Es lógico que queramos copiar los éxitos de los ingenieros de construcción de computadores, y que tratemos de escribir nuestros programas usando "cápsulas de programación" intercambiables.

      Nuestro principal problema es que cada programa debe ser construído casi desde la nada. Mientras que cuando una computadora se descompone basta que el técnico la destape y le sustituya la pieza defectuosa, cuando un programa no funciona el programador debe hacerle una autopsia completa para arreglarlo. En el primer caso, la pieza mala va a parar a Miami, Taiwan o a otro lado, en donde tal vez la reparan. Además, como todas las partes son iguales, pueden producirse en una línea de montaje.

      Pero cuando un programador le da mantenimiento a un sistema, su trabajo es el del cirujano, quien opera hasta que obliga al programa a funcionar correctamente. Un programa siempre es diferente a cualquier programa anterior.

      Hoy en día sabemos que el costo más alto en el ciclo de vida de los sistemas es el mantenimiento. Queremos masificar la producción de programas, tratando de usar ensamblaje en masa para reducir este costo. Y para eso necesitamos que los programas estén hechos de piezas intercambiables, los que llamamos módulos.

      La programación modular busca la reutilización de componentes de programación, y se basa en el uso de bibliotecas de programas. Escribimos programas modulares para que cuando alguna parte se descomponga baste arreglar sólo el módulo que ha fallado.

      Pero todavía no sabemos cómo reutilizar completamente programas, y sus partes. A diferencia del mundo de los semiconductores, el universo de discurso del programador es mucho más hostil y diverso. En los Sistemas de Información debemos lidiar con personas y modos de ser diferentes: a ningún Gerente puede parecerle bien que el programador le diga cómo debe ser su empresa, lo que obliga al programador a hacer un programa especializado para cada empresa, y para cada Gerente.

Programación por Objetos

      La Programación por Objetos (OOP) es la agregación de algunos trucos de programación descubiertos al través de los años. Por eso, la base de OOP es la abstracción de datos, expresada en los Tipos Abstractos de Datos (ADTs), unida a sus dos cualidades distintivas: Herencia y Polimorfismo.

{ SIN Herencia }
TYPE
  Punto_T = RECORD
   x,y : INTEGER
  END;

  Circulo_T = RECORD
    p : Punto_T;
    r : REAL;
  END;

PROCEDURE Mueva(
  VAR p: Punto_T);

VAR
  p : Punto_T;
  c : Circulo_T;
BEGIN
  p.x   := ...
  c.p.y := ... { .p es FEO }
  c.p.r := ...
  Mueva(p);
  Mueva(c.p); { ¡.p .p .p! }
END;

{ CON Herencia }
TYPE
  Punto_T = OBJECT
   x,y : INTEGER
  END;

  Circulo_T = OBJECT (Punto_T)

     r : REAL;
  END;

  PROCEDURE Mueva(
    VAR p: Punto_T);

  VAR
    p : Punto_T;
    c : Circulo_T;
  BEGIN
    p.x := ...
    c.y := ...   { SIN .p }
    c.r := ...   { ¡Bonito! }
    Mueva(p);
    Mueva(c);  { Nada de .p }
  END;

      Pascal es el lenguaje que legitimó, más que otros, el uso de tipos de datos. Esta construcción aumenta la sintáxis de los lenguajes tradicionales permitiéndole al programador definir nuevas variables con base en las anteriores. Esto no es novedad, pues desde la década de los sesenta ya el programador COBOL pudo usar algo similar, plasmado en los niveles de los datos en el DATA DIVISION. La Figura 2 es un ejemplo del uso de Tipos de Datos en Pascal.

      La herencia es una facilidad puramente sintáctica del lenguaje de programación que permite extender un tipo de datos, agregándole al final nuevos campos. Como se muestra en la Figura 2, el efecto de la herencia puede simularse en la mayoría de los lenguajes tradicionales, pero el resultado es un programa menos elegante.

      Como cualquier variable del tipo extendido tiene como prefijo al tipo base, entonces cualquier función que utiliza una variable del tipo base puede también aplicarse al tipo extendido. Es por eso que en la columna derecha de la Figura 2 el procedimiento Mueva() se puede aplicar a las variables "p" y "c" indistintamente: como "c" es una variable de tipo Circulo_T necesariamente contiene a una variable de tipo Punto_T, sobre la que el procedimiento Mueva() puede operar.

      La reutilización de componentes, tan mentada por los adeptos a la OOP, es precisamente la posibilidad de usar una función sobre un tipo extendido. Pero en realidad esto no es nuevo, como puede verse en la columna izquierda de la Figura 2, en la que basta incluir una referencia a un campo en un registro (.p) para obtener el mismo efecto que se logra por medio de la herencia. La herencia es "azúcar sintáctico"; pero ¡qué rico que sabe!

      El otro componente importante de la programación por objetos es el uso del polimorfismo, que se implementa por medio del uso de punteros a funciones. Cuando se usa herencia para extender de muchas formas un tipo de datos, puede resultar luego conveniente que el procedimiento que se use para operar sobre un dato dependa del dato en sí, aunque en el programa no esté especificado exactamente cuál es ese procedimiento.

       Punto_T        PROCEDURE Punto_T.Dibuje();   VIRTUAL;
          ^
        /   \
      /       \
     __     +-----+
    /  \    |     |  PROCEDURE Circulo_T.Dibuje();  VIRTUAL;
   |    |   |     |
    \__/    +-----+  PROCEDURE Cuadrado_T.Dibuje(); VIRTUAL;

Circulo_T  Cuadrado_T

VAR
  arreglo : ARRAY [1..N] OF ^Punto_T;
  p : Punto_T;
  c : Circulo_T;
  r : Cuadrado_T;

BEGIN
  { ... }
    arreglo[3] := ADDR(p);
    arreglo[2] := ADDR(c);
    arreglo[1] := ADDR(r);
  { ... }
  FOR i := 1 TO N DO BEGIN
    arreglo[i]^.Dibuje;    { ligamiento dinámico }
  END;

      Por ejemplo, en la Figura 3 se muestra una jerarquía de objetos en que, por medio de la herencia, se extiende el tipo de datos Punto_T a un Circulo_T o a un Cuadrado_T. Es natural que el procedimiento para desplegar un círculo sea totalmente diferente al que despliega un cuadrado. Sin embargo, ambos objetos tiene en común un procedimiento llamado Dibuje() que permite desplegar variables de tipo Punto_T, que es el tipo base para Circulo_T y Cuadrado_T.

      El código al final de la Figura 3 muestra cómo es posible tener un arreglo de punteros a variables de tipo Punto_T, en el que el procedimiento a usar para hacer el despliegue se escoge en tiempo de ejecución. Para que la decisión de cuál es "polimórficamente" el procedimiento que debe usarse para operar sobre una variable se tome en tiempo de ejecución, lo que se hace es almacenar en cada variable la dirección del procedimiento que le corresponde. Así, la variable "p" tendrá un puntero al procedimiento Punto_T.Dibuje(), "c" a Circulo_T.Dibuje() y "r" a Cuadrado_T.Dibuje(). A estas operaciones Dibuje() se les conoce como métodos virtuales, pues es en tiempo de ejecución cuando se decide cuál de ellas será invocada para cada una de las variables.

Usos de OOP

      El campo en que mayor impacto tiene la Programación por Objetos es en el Diseño de Interfaces Hombre-Máquina, pues es muy natural capturar la estructura de los objetos que pueden desplegarse en una pantalla usando una jerarquía de tipos. Pero en casi todos los demás campos el uso de jerarquías no rinde tantos beneficios como en el campo de los gráficos y las pantallas. Sin embargo, como la interfaz de un programa es muy importante, la mayoría de los programadores están aprendiendo a usar las metodologías orientadas a objetos para poder escribir programas que compitan en el mercado. Prácticamente todos los programas modernos deben tener una interfaz programada usando OOP, o de lo contrario el programa será rechazado por los usuarios finales, lo que en parte explica la atención que ha recibido esta nueva tecnología.

Otras nociones de Objetos

      La programación por objetos ha influenciado mucho la forma de escribir programas. Pero tal vez su impacto más grande no ha sido ahí, pues también ha ayudado a que los usuarios de las computadoras esperen más de sus programas.

      Como los programas modernos necesitan una sofisticada interfaz, casi todos incluyen mucho código que es OOP. Pero lo cierto es que ese código sirve más que todo para que el programa sea amigable, pues el algoritmo que el programa ejecuta en muchos casos no depende de la forma en que se haga la entrada-salida. Como todos los programas modernos usan OOP, se ha generalizado el uso del término "Objeto" para que también incluya paradigmas de uso de programas, con lo que OOP ya no es sólo una tecnología de programación.

      La casa Borland ha sido la abanderada de la nueva "Tecnología por Objetos", pues sus programas le crean al usuario la impresión de que manipulas "cosas". De esta manera el usuario ve en su pantalla un símbolo que puede tomar con el ratón, y moverlo para que el resultado sea la ejecución del programa. Esta forma de interacción difiere sustancialmente de la antigua, en que el usuario debía escribir comandos crípticos para obtener resultados.

      Aunque el paradigma de la tecnología por objetos fue introducido a las masas por la compañía Apple en sus computadores McIntosh, en realidad es IBM quien le da gran publicidad al decir que OS/2, su nuevo sistema operativo para la plataform x86, introduce el paradigma de "Arrastre y tire" (Drag && drop).

      En el campo de Diseño de Sistemas también se ha aumentado la tecnología para incluirle objetos. Los clásicos del Análisis Estructurado, De Marco, Yourdon y Constantine, han escrito varios libros sobre la manera en que puede lograrse un diseño por objetos. En los nuevos Diagramas de Flujo de Datos del diseño por objetos se da cabida no sólo a los procesos y los archivos, sino también a los objetos. "Lo que es bueno para el ganso, es bueno para la gansa".

      Lo cierto es que de tanto oir el término OOP, ya suena bien. Es la palabrita de la tecnología de moda.

Evaluación

      Espero que usted pueda diferenciar la técnica de programación por objetos del paradigma de arrastre y tire. En el universo de las ideas, tienen relación. Pero en la práctica son muy diferentes, y también tienen usos muy distintos.

      La programación por objetos es la agregación de varias técnicas de programación que se han desarrollado con el correr del tiempo. La mayor contribución técnica que representa la programación por objetos es que extiende las ideas básicas de la programación modular, pues propicia el uso no sólo de bibliotecas de programas, sino que también propone que los datos que aparecen en los programas sean considerados parte sustantiva del algoritmo computacional. Esta tecnología sirve para programar sistemas operativos, sistemas de graficación, o de tiempo real, y todas las demás aplicaciones sofisticadas de la computación.

      Sin embargo, OOP no es una tecnología que vaya a resolver todos nuestros problemas de computación. Las panaceas no existen, y los computólogos nos vemos obligados a conocer cada vez más técnicas para resolver los desafiantes problemas del mundo actual. Siempre ha sido muy difícil programar, y siempre lo será. Siempre encontraremos problemas que desafían nuestros últimos avances tecnológicos; la tecnología es como el dinero: nunca se tiene suficiente.

      ¿Qué relación tienen OOP y los 4GLs? Creo que en realidad tienen poca relación, pues los programas que se usan en Sistemas de Información no requieren estructuras de datos sofisticadas, salvo en el manejo de interfaces. Como el 4GL tiene su propio manejador de interfaces, el beneficio directo de OOP para los 4GLs es el uso del paradigma de arrastre y tire. Programas generados por un 4GL que incorporan este paradigma son muchos más simples de usar para los usuarios finales.

      No quiero sin embargo ser tajante en mi afirmación de que OOP sobra para los 4GLs. Siempre podremos encontrar un problema que nos obligue a emplear toda la maquinaria computacional de que disponemos para resolverlo.

      Lo que si afirmo es que la tecnología OOP no aumentará en varios órdenes de magnitud la productividad de los programadores. Los 4GLs lo lograron, pues son la tecnología para construir Sistemas de Información, aunque todavía buscamos mejorar estas herramientas.

      Si usted no entendió bien mi explicación sobre qué es herencia o polimorfismo, no se preocupe a menos que trabaje programando. OOP es para una tecnología para programadores.

      ¿Es necesario que las empresas capaciten a sus programadores en OOP? Mi respuesta es que sí, pues de lo contrario la empresa o sus programadores se retrasarían tecnológicamente. Pero esto no quiere decir que esos programadores programarán más "rápido"; quiere decir que programará más "mejor".

Conclusión

      Ya he formado parte de tres religiones de programación: Fortran, Prolog y Pascal; hoy en día muchos me consideran un misionero del C++. Digo esto porque soy consciente de que los programadores siempre tenemos opiniones muy fuertes respecto a nuestro lenguaje preferido.

      Aunque no pueda emitir una opinión totalmente objetiva, creo que la Tecnología de los Objetos nos traerá grandes beneficios. Nos permite a los programadores escribir y diseñar mejores sistemas, y más modulares. Ayuda a los usuarios, pues obtienen programas mucho más fáciles de usar.

      Lo que pasa es que el programador por objetos no necesariamente desarrolla Sistemas de Información con mayor velocidad. Simplemente, tiene una mejor formación, lo que le permite escribir mejores programas.

      ¿Es necesaria la capacitación en OOP? Creo que la mejor respuesta está en la siguiente analogía: Si nuestra misión no fuera escribir programas, sino más bien hacer autos, entonces estoy seguro de que la compañía Mercedes Benz estaría desde hace mucho tiempo capacitando a sus empleados en la nueva tecnología. Le pregunto: ¿construye usted Mercedes Benz?

╔══════════╤════════╤════════════════════════════════╗─────┐
║          │        │              ┌─Subrutinas ───┐ ║     │
║          │ Turbo  │ Programación ├─Módulos ──────┤ ║     │
║          │ Pascal │ Estructurada ├─IF-THEN-ELSE ─┤ ║     │
║          │        │              ├─WHILE-REPEAT ─┤ ║     │
║          │ Modula │              └─GO TO ────────┘ ║     │
║          ├────────┼────────────────────────────────╢     │
║          │ Turbo  │       ┌─Tipos de Datos ──────┐ ║     │
║          │ Pascal │ ADTs  ├─Encapsulamiento ─────┤ ║ A   │
║          │ v5.5   │       ├─Ocultamiento  ───────┤ ║  D  │
║          │        │       └─Iteradores ──────────┘ ║   A │
║  ╔════╗  └────────┴────────────────────────────────╫─┐   │
║  ║ ╔══╝              ╔══════════════════════╦═══╗  ║ │   │
║  ║ ║     ║      ║    ║ Herencia             ║ O ║  ║ │   │
║  ║ ║   ══╬══  ══╬══  ╟──────────────────────╢ O ║  ║ │   │
║  ║ ║     ║      ║    ║ Polimorfismo         ║ P ║  ║ │   │
║  ║ ╚══╗              ╚══════════════════════╩═══╝  ║ │   │
║  ╚════╝  ┌────────┬────────────────────────────────╫─┘   │
║          │        │ Sobrecarga de Identificadores  ║     │
║          │ Prolog ├────────────────────────────────╢     │
║          │        │ Sobrecarga de Operadores       ║     │
║          └────────┴────────────────────────────────╫─────┘
║                   ┌────────────────────────────────╢
║                   │ Constructores y Destructores   ║
╚═══════════════════╧════════════════════════════════╝

Glosario

Abstracción:

Proceso por medio del que se elimina información para lograr tratar cosas diferentes como si fueran iguales. De esta forma se separan las características de un ente en dos grupos, el de las características que importa y el de las que sobran, para tomar en cuenta únicamente aquellas relevantes a la solución de un problema.

Especificación:

Proceso por medio del que se definen las características de un ente.

Procedimiento o rutina:

Facilidad sintáctica de los lenguajes de programación que le permiten al programador aislar la solución de un problema particular en un módulo. Mediante el uso de procedimientos es posible aplicar la abstracción por parametrización y por especificación.

Abstracción por parametrización:

Uso de argumentos en procedimientos y rutinas.

Abstracción por especificación:

Disciplina de programación que busca que el programador defina qué es lo que hace cada uno de los módulos que componen un programa o sistema, aún antes de realizar la implementación.

Módulos:

Partes que componen un sistema, que generalmente se construyen de forma que sean independientes unas de otra. En general se busca que al hacer cambios en un módulo no sea necesario hacerlo en otros. En estos casos, se dice que los módulos tienen una cohesión baja.

Programación Estructurada:

Conjunto de prácticas y disciplinas de programación que se basan en el uso de Abstracción por parametrización y por especificación para construir sistemas. Además, un lenguaje de programación soporta la Programación Estructurada si cuenta con las construcciones sintácticas IF-THEN-ELSE, WHILE-REPEAT, CASE, procedimientos y argumentos. Un programa estructurado nunca hace uso del GO TO, y generalmente se descompone modularmente como una jerarquía de procedimientos, usando la descomposición de Arriba hacia Abajo [Top-Down].

Tipos Abstractos de Datos:

Es un el uso de una técnica de de abstracción que busca juntar en un sólo módulo toda la programación relevante a una estructura de datos en particular. Esto se logra definiendo las operaciones de un tipo de datos. Lo usual es que un ADT provea Ocultamiento de Datos y alguna forma de Encapsulamiento de datos, aunque ésta última no sea completa.

Encapsulamiento:

Facilidad de un lenguaje de programación que permite definir un tipo de datos junto a sus operaciones, con el fin de obtener un tipo abstracto de datos.

Ocultamiento de Datos:

Facilidad de un lenguaje de programación que permite evitar que un programador que usa un tipo abstracto de datos pueda manipular la estructura interna de una instancia. De esta manera se evita que el programador usario del tipo abstracto de datos introduzca inconsistencias en la estructura de datos.

Iteradores:

Abstracción que permite obtener todos los elementos contenidos en un tipo abastracto de datos contenedor. Los contenedores más usuales son los arreglos, las listas, los conjuntos, los árboles y en menor grado los grafos.

Herencia (Extensión de tipos):

Facilidad del lenguaje de programación que permite extender un tipo de datos, agregando al final nuevos campos. El efecto de la herencia puede simularse en la mayoría de los lenguajes tradicionales, pero el resultado es un programa menos elegante y en muchos casos mucho más difícil de programar.

Polimorfismo (Funciones Virtuales):

Un lenguaje de programación que soporta polimorfismo permite diferir la definición de la operación que debe aplicarse un objeto al momento en que esa operación es necesaria. De esta manera, el programador no necesita conocer el objeto sobre el que opera.
      Cuando se usa herencia para extender de muchas formas un tipo de datos, resulta luego conveniente que el procedimiento que se use para operar sobre un dato dependa del dato en sí, aunque el programador no haya especificado exactamente cuál es ese procedimiento.

Sobrecarga de Identificadores:

Facilidad de un lenguaje de programación que permite usar el mismo identificador para para procedimientos diferentes. Los procedimientos se diferencian por sus argumentos y no por su nombre.

Sobrecarga de Operadores:

Facilidad de un lenguaje de programación que le permite al programador definir un nuevo tipo de datos que puede usarse en expresiones. En general, la sobrecarga de operadores implica el uso de los operadores aritméticos [+ - * / ^] en expresiones.

Método:

Operación que es definida junto a un tipo de datos en aquellos lenguajes que soportan encapsulamiento.

Mensaje:

Nombre del método con que se invoca a una operación sobre un objeto. Los términos método y operación son sinónimos, pero uno se usa en el contexto de Programación por Objetos y el otro en el de Abstracción de Datos.

Programación Orientada a los Objetos [OOP]:

Uso de un técnicas de Abstracción de Datos en un lenguaje que también soporta Encapsulamiento, Herencia y Polimorfismo.

Funciones Virtuales:

Polimorfismo.

Programación por Objetos:

Programación Orientada a los Objetos.

Constructores y Destructores:

Facilidad de un lenguaje de programación que le permite al programador definir uno o varios procedimientos especiales que se encargan de inicializar y destruir las variables de un tipo, y que además son invocadas automáticamente por el compilador. En genereal, la misión principal de los destructores es devolver la memoria dinámica asociada a un objeto.

Notas de pie de página

Bibliografía

Indice

[-]	Resumen
[-]	Introducción
[-]	Cronología de los lenguajes de programación
[-]	Lenguajes de Cuarta Generación
[-]	Tipos de programas
[-]	Modularidad
[-]	Programación por Objetos
[-]	Usos de OOP
[-]	Otras nociones de Objetos
[-]	Evaluación
[-]	Conclusión
[-]	Glosario
	Notas de pie de página
	Bibliografía
	Indice
	Acerca del autor
	Acerca de este documento
	Principio Indice Final

Acerca del autor

Adolfo Di Mare: Investigador en la Escuela de Ciencias de la Computación e Informática de la Universidad de Costa Rica, en donde ostenta el rango de Profesor Asociado. Dirige la Cátedra de Programación y es el presidente del Consejo de Area de Ingeniería de Sistemas. Es Maestro Tutor del Stvdivm Generale de la Universidad Autónoma de Centro América, en donde ostenta el rango de Catedrático y funge como Consiliario Académico. Obtuvo la Licenciatura en la Universidad de Costa Rica y la Maestría en Ciencias en la Universidad de California, Los Angeles.

Adolfo Di Mare <adolfo@di-mare.com>

Acerca de este documento

Referencia:	Di Mare, Adolfo: La programación por objetos en los sistemas de información, Revista Acta Académica, Universidad Autónoma de Centro América, Número 13, pp [35­41], ISSN 1017­7507, Noviembre 1993.
Internet:	http://www.uaca.ac.cr/actas/1993nov/oopsig.htm http://www.di-mare.com/adolfo/p/oopsig.htm
Autor:	Adolfo Di Mare <adolfo@di-mare.com>
Contacto:	Apdo 7637-1000, San José Costa Rica Tel: (506) 234-0701       Fax: (506) 224-0391
Revisión:	UACA, Mayo 1998
Visitantes:

ACTA ACADEMICA, UACA.