1. Un poco de historia

1. Un poco de historia
En la actualidad el uso de las computadoras en las diversas actividades humanas es algo demasiado común
para ser ignorado. ¿Quién no ha escuchado hablar de un monitor VGA o de una computadora IBM? Esto se
debe a que en los últimos años el desarrollo de los sistemas computacionales (hardware), ha sido vertiginoso:
la diferencia entre un procesador 8086 de principios de los ochentas y uno 486 de hoy día es evidente. La
creciente aparición de redes locales (LAN's) y la expansión de Internet nos hace preguntarnos ¿hasta dónde
vamos a llegar? La respuesta, personalmente, no la sé. Lo que sí sé es que la popularización de los sistemas de
cómputo depende de la aceptación que tengan entre los usuarios, es decir, nadie usaría una computadora para
su trabajo si pensase que de esa manera se va a volver más difícil que haciéndolo sin ella. Por esta razón es
importante que los usuarios comprendan las ventajas que las computadoras ofrecen. En este artículo deseo
mostrar un concepto que ha sido "escuchado al pasar" más de una vez en los últimos años, principalmente por
programadores aficionados: el concepto de Programación Orientada a Objetos (POO.1
En contraste con el enorme avance que hemos podido presenciar en la creación de nuevos sistemas de
cómputo, cada vez más rápidos y pequeños, la ingeniería del software ha progresado más lentamente.
Definición 1. Un lenguaje de programación es un conjunto limitado de palabras y símbolos que representan
procedimientos, cálculos, decisiones y otras operaciones, como control de procesos, que puede ejecutar una
computadora.
Un programa es un conjunto de instrucciones que son dadas a la máquina mediante un lenguaje de
programación. Los lenguajes, en muy grandes razgos, están clasificados conforme qué tan amigables son para
el usuario. Por ejemplo, los lenguajes como ensamblador son considerados lenguajes de bajo nivel y los
lenguajes como BASIC de alto nivel por estar "más cerca del usuario". Los lenguajes de alto nivel
normalmente son parecidos al inglés, aunque no siempre. Un ejemplo de un lenguaje de alto nivel no parecido
al inglés es Visual BASIC de la versión española de Excel, versión 5.0, que es más bien parecido al español.
Las computadoras generalmente operan en lenguaje máquina que es el lenguaje utilizado por la "unidad
central de procesamiento" (o procesador). Por esta razón es obvio preguntarse ¿cómo es que la computadora
entiende lo que le digo si no lo escribí en lenguaje máquina?
Definición 2. Un intérprete es un programa que, como su nombre lo indica, interpreta símbolos en un
programa y los traduce a lenguaje máquina conforme deban ser ejecutados.
Definición 3. Un compilador es un programa muy utilizado en lenguajes de alto nivel que permite traducir un
programa escrito en un lenguaje dado a lenguaje máquina para después ser ejecutado.
El compilador traduce el programa completo antes de que sea ejecutado, a diferencia del intérprete que
traduce las instrucciones una por una. En consecuencia, la ejecución de un programa vía compiladorejecución
es más rápida que la ejecución mediante un intérprete. Es por esta razón que son preferidos los compiladores
sobre los intérpretes. Actualmente existen compiladores para toda clase de lenguajes de programación, desde
ensamblador, pasando por BASIC, hasta C++.
Ahora veamos un poco de historia "simplificada", desde el punto de vista de la ingeniería del software. Los
primeros lenguajes de programación populares como BASIC y FORTRAN se difundieron rápidamente por su
simplicidad y estructura parecidas al álgebra. La modelación de procesos era simpleal principio, pero cuando
se trataba de crear códigos legibles empezaban las dificultades: aunque las líneas de comentarios eran
permitidas, los programas escritos en un estilo de "espaguetti" eran aun así demasiado complejos. ¿E1
resultado? Limitantes en el grado de complejidad, y por ende de potencia, del programa.
1
Definición 4. La programación estructurada es la escritura de programas de manera que
• el programa tiene un diseño modular: el código del programa está dividido en módulos o segmentos
de código que son ejecutados conforme sea requerido;
• los módulos son diseñados de modo descendente: los problemas se dividen de tal manera que las
partes complejas del programa sean implementadas (realizadas) por módulos independientes que a
su vez pueden invocar a otros módulos.
Para remediar esta situación aparecieron, en la segunda mitad de la década de los sesentas, los lenguajes
basados en programación estructurada. La programación estructurada, al ser modular, permitía al programador
dividir el código del programa en partes de manera que, al trabajar con problemas complejos, se podía aplicar
la filosofía de "divide y vencerás". Por esta razón la programación estructurada fue ganando terreno entre los
programadores: los códigos indecifrables de la programación "espaguetti" fueron reemplazados por códigos
más legibles de programación estructurada. Lenguajes de programación estructurada típicos son Pascal y C.
Una propiedad característica de la programación estructurada es la ausencia prácticamente total de las
sentencias de transferencia de control incondicionales, como el GOTO de BASIC.
2. Pero, ¿qué es?
Creo que, hasta aquí, todos los conceptos de arriba son comprendidos por una amplia gama de usuarios.2
Ahora veamos qué onda con la programación orientada a objetos. La POO (para más corto) no es un lenguaje
de programación. (¡¿Entonces qué es?!) Bueno, no vayamos tan rápido: primero veamos por qué es necesaria.
Como ya dije antes, la programación estructurada permite crear programas más complejos que la
programación "espaguetti", sin embargo también tiene sus limitantes. Los programadores, no sé por qué,
nunca están conformes, y es por ello que siempre tratan de crear programas más grandes y más complejos, y
es por esta razón que inclusive la programación estructurada se queda "chiquita" junto a la complejidad de
algunos proyectos que, dicho sea de paso, llegan a ser incontrolables. Aquí es donde interviene la POO.
(Ahora sí.) La POO es una nueva manera de "atacar" los problemas de programación, especialmente los
relativos a grandes y medianos proyectos. Esto no significa que vayamos a tirar a la basura a la programación
estructurada y que todo el código que no esté escrito rnediante POO sea inútil, al contrario, lo que quiere decir
es que hemos encontrado una manera más fácil de implementar la programación estructurada. En efecto, la
POO se ha basado en la programación estructurada para implementar conceptos innovadores que simplifican
la creación de programas: la POO permite dividir un problema en pequeñas unidades lógicas de código,
independientes del resto del programa, que interactúan entre sí. A estas pequeñas unidades lógicas de código
se les ha denominado objetos para establecer una analogía entre las mismas y los objetos materiales del
mundo real. Para comprender el código de aplicaciones complejas creadas mediante POO los desarrolladores
del mismo sólo necesitan entender los mensajes que los objetos se envían entre sí para entender cómo
funciona el programa. Para enviarle una orden a un objeto sólo es necesario proporcionarle la información de
lo que queremos que haga, sin preocuparnos por entender exactamente cómo se va a ejecutar la tarea. (¡¿Pero
en sí qué es un objeto?!) Todos los lenguajes orientados a objetos, por definición, tienen tres cosas en común:
los objetos, el polimorfismo y la herencia. Veamos rápidamente qué significa esto.
3. Objetos
Un objeto es un ente lógico que contiene datos e instrucciones que manipulan dichos datos. El enlace de las
instrucciones junto con los datos de esta manera especial se conoce como encapsulamiento. Para todos los
fines y propósitos, un objeto es una vsriable de un tipo deflnido por el usuario.3 Al principio puede parecer
extraño, pensar que un objeto que reúne instrucciones y datos, es una variable. No obstante, en POO esto es
precisamente lo que sucede. Cuando se define un objeto, se está creando un nuevo tipo de dato.
4. Polimorfismo
2
Los lenguajes de POO soportan el polimorfismo, lo cual quiere decir esencialmente, que un mismo nombre
puede ser utilizado para varios propósitos levemente distintos, pero relacionados entre sí. El polimorfismo
permite que se use un nombre para especificar una clase general de acción. No obstante, dependiendo del tipo
de dato con el cual se esté tratando, se implementará una acción específica. Un ejemplo pequeñito, usando
Turbo Pascal, puede ser:
• Mediante programación estructurada, definimos dos tipos de datos, R2−Vector y R3−Vector y
definimos dos funciones diferentes para obtener su norma:4
program Vector;
type
R2Vector = record
x, y : Real
end;
R3Vector = record
x, y, z : Real
end;
var
Vector2 : R2Vector;
Vector3 : R3Vector;
function R2Abs (Vector : R2Vector) : Real
begin
R2Abs = Sqrt (Vector.x + Vector.x + Vector.y + Vector.y);
end;
function R3Abs (Vector : R3Vector) : Real;
begin
R3Abs := Sqrt (Vector.x + Vector.x + Vector.y + Vector.y
+ Vector.z + Vector.z);
end;
begin
with Vector2 do
begin
x := 1;
y := 1;
end;
WriteLn;
with Vector3 do
begin
x = 1;
y = 1;
z = 1;
end;
WriteLn (R2Abs (Vector2));
WriteLn (R3Abs (Vector3));
end.
• Ahora usemos el polimorfismo de POO para "unificar" las funciones:
3
program Vector;
type
R2Vector = object
x, y : Real;
function Abs : Real;
end;
R3Vector = object
x, y, z : Real;
function Abs : Real;
end;
var
Vector2 : R2Vector;
Vector3 : R3Vector;
function R2Vector.Abs : Real;
begin
Abs := Sqrt (x + x + y + y);
end;
function R3Vector.Abs : Real
begin
Abs := Sqrt (x + x + y + y + z + z);
end;
begin
with Vector2 do
begin
x := 1;
y := 1;
end;
WriteLn;
with Vector3 do
begin
x := 1;
y := 1;
z := 1;
end;
WriteLn (Vector2.Abs);
WriteLn (Vector3.Abs);
end.
Ahora tenemos una sola función para determinar el valor absoluto de ambas variables−objeto R2−Vector y
R3−Vector. Obviamente es más fácil, al trabajar con programas grandes, pensar en la función Abs que en dos
funciones distintas R2Abs y R3Abs que, en general, hacen lo mismo.
5. Herencia
La herencia es un proceso por medio del cual un objeto puede adquirir las propiedades de otro. Esto es
importante porque permite dar soporte al concepto de clasificación. De hecho, gran parte del conocimiento
4
que tenemos del mundo real está organizado jerárquicamente. Por ejemplo, la especie gato pertenece al género
de los felinos, de la familia de los félidos, del orden de los carnívoros, de la clase de los mamíferos. Sin el uso
de clasificaciones, cada objeto tendría que definir de forma explícita todas su características. En cambio,
cuando se utilizan clasificaciones, se necesita definir solamente aquellas cualidades del objeto que hacen que
sea único dentro de su clase. El mecanismo de herencia es el que se encarga de que un objeto se pueda
considerar como una especialización de una clase más general. Consideremos nuevamente nuestro ejemplo.
Podemos definir el tipo R3−Vector sobre el tipo R2−Vector al modificar la definición de los tipos de la
siguiente manera:
type
R2Vector = object
x, y : Real;
function Abs : Real;
end;
R3Vector = object (R2Vector)
z : Real ;
function Abs : Real;
end;
Tenemos aquí una manera, hay que admitir que artificiosa, de mostrar la herencia de objetos. La herencia
puede ser apreciada de mejor forma con tiposobjeto jerarquizados más directamente.
La POO en realidad es muy útil para el desarrollo de todo tipo de aplicaciones, sin embargo, requiere de un
buen conocimiento de los tipos de objeto con los que se trabaja y sobre todo de práctica. El tema realmente no
termina aquí: la reutilizabilidad de los objetos y las librerías es un tema muy amplio que requiere de textos
mucho más extensos y precisos. Para saber más sobre POO en C (es decir, con C++) se puede consultar [4].
I. La orientación a objetos.
Tradicionalmente la programación se realiza de modo secuencial: se diseñan las variables y funcionalidades
que habrá de tener un programa y se escribe luego la secuencia de instrucciones que realizan la tarea deseada.
Este enfoque de arriba a abajo o de principio a fin resulta limitante cuando el tamaño del proyecto de
programación crece y cuando se considera que no es el modo "natural" en el que realizamos nuestras
actividades. Frente a él aparece, sin excluirlo, el estilo de la orientación a objetos.
La programación orientada a objetos (POO para quienes gustan de ahorrar teclas) difiere de la programación
secuencial en el hecho de que en ella la atención no esta puesta en una secuencia de operaciones sino en las
"cosas" que forman un sistema y en las operaciones que se pueden hacer sobre ellas. Por ejemplo, si la "cosa",
o en terminos de la POO, el objeto, es un archivo, entonces algunas de las operaciones pueden ser la
impresión del contenido, el despliegue en pantalla, o el cambio de nombre. Quizá se piense que tales tareas no
son diferentes de las funciones de la programación tradicional, y no lo son si consideramos el codigo
generado. Lo que distingue a la POO es que tales funciones, métodos en la terminología de la orientación a
objetos, estan integrados en una sóla estructura, que, a la vez, definen. En este sentido puede decirse que los
objetos tienen identidad, estan formados por cierta cantidad de datos definitorios, y un comportamiento, las
funciones que realiza el objeto y que le caracterizan.
Los objetos pueden ser tan diversos como una matriz, o un vector, hasta una ventana en un despliegue gráfico,
o incluso una bicicleta en un programa de juego. Más aun: un objeto puede estar formado de otros más
simples, v.g. la bicicleta se construye con tornillos, ruedas y pedales.
Podemos considerar a los objetos como estructuras complejas pues estan formados por un conjunto de datos
5
simples, o de menor complejidad, incluyendo otros tipos de objetos, y por un conjunto de funciones
definitorias de las operaciones que puede realizar el objeto. Estas estructuras no tienen que ser necesariamente
un reflejo de entidades reales, papas, casas o ecuaciones, sino que pueden definirse de acuerdo a las
necesidades del programa especifico. Por ejemplo, un método para resolver un sistema de ecuaciones lineales
no es, en la realidad, algo concreto que pueda asirse o guardarse en un cajón, sino un procedimiento de
solución, sin embargo puede crearse un objeto para dicho método. La condición es que la estructura que
formamos tenga sentido dentro del programa que estamos realizando.
Programación Orientada a Objetos
La programación orientada a objetos resuelve algunos de los problemas que se acaban de mencionar. En
contraste con las otras técnicas, ahora tenemos una telaraña de objetos interactuantes, cada uno de los cuáles
manteniendo su propio estado (Fig. 2.6).
Figura 2.6: Programación Orientada a Objetos. Los objetos del programa interactúan mandando mensajes
unos a otros.
Considera el ejemplo de listas múltiples nuevamente. El problema aquí con la programación modular es, que
tú debes crear y destruir en forma explícita tus manejadores de lista. Entonces tú usas los procedimientos del
módulo para modificar cada uno de tus manejadores.
En contraste con eso, en la programación orientada a objetos deberíamos tener tantos objetos−lista como sea
necesario. En lugar de llamar un procedimiento al que le debemos proveer el manejador de lista correcto,
mandaríamos un mensaje directamente al objeto−lista en cuestión. En términos generales, cada objeto
implementa su propio módulo, permitiendo por ejemplo que coexistan muchas listas.
Cada objeto es responsable de inicializarse y destruirse en forma correcta. Por consiguiente, ya no existe la
necesidad de llamar explícitamente al procedimiento de creación o de terminación.
Te podrías preguntar : ¿Y qué? ¿No es ésta solamente una manera más elegante de técnica de programación
modular ? Tendrías razón, si ésto fuera todo acerca de la orientación a objetos. Afortunadamente no lo es.
Empezando en los siguientes capítulos, se introducen características adicionales de orientación a objetos que
hacen de la programación orientada a objetos una técnica novedosa de programación.
Sistemas de Procesamiento
6
de Datos
Programación Orientada a Objetos
INTRODUCCION
Actualmente una de las áreas más candentes en la industria y en el ámbito académico es la orientación a
objetos. La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y
mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han
existido desde el comienzo en el desarrollo de software: la falta de portabilidad del código y reusabilidad,
código que es difícil de modificar, ciclos de desarrollo largos y técnicas de codificación no intuitivas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características básicas: debe estar basado en
objetos, basado en clases y capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos
puntos; muchos menos cumplen los tres. La barrera más difícil de sortear es usualmente la herencia.
El concepto de programación orientada a objetos (OOP) no es nuevo, lenguajes clásicos como SmallTalk se
basan en ella. Dado que la OOP. se basa en la idea natural de la existencia de un mundo lleno de objetos y que
la resolución del problema se realiza en términos de objetos, un lenguaje se dice que está basado en objetos si
soporta objetos como una característica fundamental del mismo.
El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como
un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.
Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un
dato simple, sino que contiene en su interior cierto número de componentes bien estructurados. En segundo
lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo.
ESTRUCTURA DE UN OBJETO
Un objeto puede considerarse como una especie de cápsula dividida en tres partes:
1 − RELACIONES
2 − PROPIEDADES
3 − METODOS
Cada uno de estos componentes desempeña un papel totalmente independiente:
Las relaciones permiten que el objeto se insterte en la organización y están formadas esencialmente por
punteros a otros objetos.
Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma
organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto
pueden ser heredadas a sus descendientes en la organización.
7
Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán
incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a
disposición de sus descendientes a través de la herencia.
Encapsulamiento y ocultación
Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos
relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta propiedad
(encapsulamiento), es una de las características fundamentales en la OOP.
Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan
cómo está distribuida la información o qué información hay disponible. Esta propiedad de los objetos se
denomina ocultación de la información.
Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que
contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede es que las peticiones de información
a un objeto. deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la operación
pertinente. La respuesta a estas ordenes será la información requerida, siempre que el objeto considere que
quien envía el mensaje está autorizado para obtenerla.
El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto determinado pueda ser
transportado a otro punto de la organización, o incluso a otra organización totalmente diferente que precise de
él. Si el objeto ha sido bien construido, sus métodos seguirán funcionando en el nuevo entorno sin problemas.
Esta cualidad hace que la OOP sea muy apta para la reutilización de programas.
Organización de los objetos
En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son
superiores a otros de cierto modo.
Existen varios tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un
"árbol". En otros casos puede ser más compleja.
En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.
−La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteriza por estar en el nivel más
alto de la estructura y suele recibir un nombre muy genérico, que indica su categoría especial, como por
ejemplo objeto madre, Raíz o Entidad.
−Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen
descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy
especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan al conjunto de
8
objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre
de clases o tipos si descienden de otra clase o subclase.
−Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen
descendientes. Suelen llamarse casos particulares, instancias o ítems porque representan los elementos del
conjunto representado por la clase o subclase a la que pertenecen.
Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto".
1. RELACIONES
Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos
que forman parte de la misma organización.
Las hay de dos tipos fundamentales:
−Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son
bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado
inmediatamente encima del segundo en la organización en la que ambos forman parte; asimismo, si un objeto
es padre de otro, el segundo es hijo del primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son hijos
de B; en la fig. 3, los objetos B y C son padres de F, que a su vez es hijo de ambos).
Una organización jerárquica simple puede definirse como aquella en la que un objeto puede tener un solo
padre, mientras que en una organización jerárquica compleja un hijo puede tener varios padres).
−Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la organización de la que
forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en
sí mismos (de su significado) y no de su posición en la organización.
Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario informatizado que
permita al usuario obtener la definición de una palabra cualquiera. Supongamos que, en dicho diccionario, las
palabras son objetos y que la organización jerárquica es la que proviene de forma natural de la estructura de
nuestros conocimientos sobre el mundo.
La raíz del diccionario podría llamarse TEMAS. De éste término genérico descenderán tres grandes ramas de
objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida) comprenderá las ciencias biológicas:
Biología y Medicina. El segundo (mundo), las ciencias de la naturaleza inerte: las Matemáticas, la Física, la
Química y la Geología. El tercero (hombre) comprenderá las ciencias humanas: la Geografía, la Historia, etc.
Veamos un ejemplo: estableceremos la relación trabajo entre los objetos NEWTON y OPTICA y la
interpretaremos diciendo que significa que Newton trabajó en óptica (véase la fig. 4). La relación es,
evidentemente, semántica, pues no establece ninguna connotación jerárquica entre NEWTON y OPTICA y su
interpretación depende exclusivamente del significado de ambos objetos.
La existencia de esta relación nos permitirá responder a preguntas como:
¿Quién trabajó en óptica?
9
¿En qué trabajó Newton?
¿Quien trabajó en Física?
Las dos primeras se deducen inmediatamente de la existencia de la relación trabajo. Para la tercera
observamos que si Newton trabajó en óptica automáticamente sabemos que trabajó en Física, por ser óptica
una rama de la Física (en nuestro diccionario, el objeto OPTICA es hijo del objeto FISICA). Entonces gracias
a la OOP podemos responder a la tercera pregunta sin necesidad de establecer una relación entre NEWTON y
FISICA, apoyándonos sólo en la relación definida entre NEWTON y OPTICA y en que OPTICA es hijo de
FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de información que tendremos
que definir para todo el diccionario será mínima.
2. PROPIEDADES
Todo objeto puede tener cierto número de propiedades, cada una de las cuales tendrá, a su vez, uno o varios
valores. En OOP, las propiedades corresponden a las clásicas "variables" de la programación estructurada.
Son, por lo tanto, datos encapsulados dentro del objeto, junto con los métodos (programas) y las relaciones
(punteros a otros objetos). Las propiedades de un objeto pueden tener un valor único o pueden contener un
conjunto de valores mas o menos estructurados (matrices, vectores, listas, etc.). Además, los valores pueden
ser de cualquier tipo (numérico, alfabético, etc.) si el sistema de programación lo permite.
Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar de unos objetos a
otros. En consecuencia, un objeto puede tener una propiedad de maneras diferentes:
−Propiedades propias. Están formadas dentro de la cápsula del objeto.
−Propiedades heredadas. Están definidas en un objeto diferente, antepasado de éste (padre,"abuelo", etc.). A
veces estas propiedades se llaman propiedades miembro porque el objeto las posee por el mero hecho de ser
miembro de una clase.
3. METODOS
Una operación que realiza acceso a los datos. Podemos definir método como un programa procedimental o
procedural escrito en cualquier lenguaje, que está asociado a un objeto determinado y cuya ejecución sólo
puede desencadenarse a través de un mensaje recibido por éste o por sus descendientes.
Son sinónimos de 'método' todos aquellos términos que se han aplicado tradicionalmente a los programas,
como procedimiento, función, rutina, etc. Sin embargo, es conveniente utilizar el término 'método' para que se
distingan claramente las propiedades especiales que adquiere un programa en el entorno OOP, que afectan
fundamentalmente a la forma de invocarlo (únicamente a través de un mensaje) y a su campo de acción,
limitado a un objeto y a sus descendientes, aunque posiblemente no a todos.
Si los métodos son programas, se deduce que podrían tener argumentos, o parámetros. Puesto que los métodos
pueden heredarse de unos objetos a otros, un objeto puede disponer de un método de dos maneras diferentes:
−Métodos propios. Están incluidos dentro de la cápsula del objeto.
−Métodos heredados. Están definidos en un objeto diferente, antepasado de éste (padre,"abuelo", etc.). A
veces estos métodos se llaman métodos miembro porque el objeto los posee por el mero hecho de ser
miembro de una clase.
10
Polimorfismo
Una de las características fundamentales de la OOP es el polimorfismo, que no es otra cosa que la posibilidad
de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno,
con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases
diferentes. Estos objetos recibirían el mismo mensaje global pero responderían a él de formas diferentes; por
ejemplo, un mensaje "+" a un objeto ENTERO significaría suma, mientras que para un objeto STRING
significaría concatenación ("pegar" strings uno seguido al otro)
Demonios
Es un tipo especial de métodos, relativamente poco frecuente en los sistemas de OOP, que se activa
automáticamente cuando sucede algo especial. Es decir, es un programa, como los métodos ordinarios, pero se
diferencia de estos porque su ejecución no se activa con un mensaje, sino que se desencadena
automáticamente cuando ocurre un suceso determinado: la asignación de un valor a una propiedad de un
objeto, la lectura de un valor determinado, etc.
Los demonios, cuando existen, se diferencian de otros métodos por que no son heredables y porque a veces
están ligados a una de las propiedades de un objeto, mas que al objeto entero.
CONSIDERACIONES FINALES
Beneficios que se obtienen del desarrollo con OOP
Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación cotidianamente:
procesamiento de imágenes y sonido, bases de datos multimediales, automatización de oficinas, ambientes de
ingeniería de software, etc. Aún en las aplicaciones tradicionales encontramos que definir interfases
hombre−máquina "a−la−Windows" suele ser bastante conveniente.
Lamentablemente, los costos de producción de software siguen aumentando; el mantenimiento y la
modificación de sistemas complejos suele ser una tarea trabajosa; cada aplicación, (aunque tenga aspectos
similares a otra) suele encararse como un proyecto nuevo, etc.
Todos estos problemas aún no han sido solucionados en forma completa. Pero como los objetos son portables
(teóricamente) mientras que la herencia permite la reusabilidad del código orientado a objetos, es más sencillo
modificar código existente porque los objetos no interaccionan excepto a través de mensajes; en consecuencia
un cambio en la codificación de un objeto no afectará la operación con otro objeto siempre que los métodos
respectivos permanezcan intactos. La introducción de tecnología de objetos como una herramienta conceptual
para analizar, diseñar e implementar aplicaciones permite obtener aplicaciones más modificables, fácilmente
extendibles y a partir de componentes reusables. Esta reusabilidad del código disminuye el tiempo que se
utiliza en el desarrollo y hace que el desarrollo del software sea mas intuitivo porque la gente piensa
naturalmente en términos de objetos más que en términos de algoritmos de software.
Problemas derivados de la utilización de OOP en la actualidad
Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema sin embargo surge
en la implementación de tal sistema. Muchas compañías oyen acerca de los beneficios de un sistema orientado
a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva
cultura que es ajena a los programadores actuales. Específicamente los siguientes temas suelen aparecer
repetidamente:
Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma única. Involucra la
11
conceptualización de todos los elementos de un programa, desde subsistemas a los datos, en la forma de
objetos. Toda la comunicación entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma
en que están escritos los programas orientados a objetos actualmente; al hacer la transición a un sistema
orientado a objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder usarlo.
Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un sistema orientado a
objetos, en la práctica existen muchas dependencias. Muchos lenguajes orientados a objetos están
compitiendo actualmente para dominar el mercado. Cambiar el lenguaje de implementación de un sistema
orientado a objetos no es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia múltiple
mientras que SmallTalk no lo soporta; en consecuencia la elección de un lenguaje tiene ramificaciones de
diseño muy importantes.
Determinación de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia
es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definición de las
clases es más un arte que una ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se
deben crear clases específicas para la aplicación que se este desarrollando. Luego, en 6 meses ó 1 año se da
cuenta que las clases que se establecieron no son posibles; en ese caso será necesario reestructurar la jerarquía
de clases devastando totalmente la planificación original.
Performance. En un sistema donde todo es un objeto y toda interacción es a través de mensajes, el tráfico de
mensajes afecta la performance. A medida que la tecnología avanza y la velocidad de microprocesamiento,
potencia y tamaño de la memoria aumentan, la situación mejorará; pero en la situación actual, un diseño de
una aplicación orientada a objetos que no tiene en cuenta la performance no será viable comercialmente.
Idealmente, habría una forma de atacar estos problemas eficientemente al mismo tiempo que se obtienen los
beneficios del desarrollo de una estrategia orientada a objetos. Debería existir una metodología fácil de
aprender e independiente del lenguaje, y fácil de reestructurar que no drene la performance del sistema .
12