Ejemplo De Mensajes: si el objeto pato desea destruir la computadora debe
enviar un mensaje al objeto martillo.
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.
4. 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 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 ,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.
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?
¿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, apoyandonos 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. Métodos
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.
Polimorfísmo
Una de las características fundamentales de la OOP es el polimorfísmo, 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.
5. 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 interfaces
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 extensibles 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 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.
Determinacion 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.
Trabajo enviado por:
John Clever Rodríguez Sedano
