El Rinconcito Informático

Diccionario Informático Ampliado

Objetos.

Nos dicen los libros que un objeto en informática es una simulación de la vida real. Bueno, no me lo creo, sí podemos forzar a que tenga su parecido, e inclusive a ser utilizado para explicarlos, siempre que se trate de un ser vivo, con capacidad de reproducción.

Como "para muestra bien vale un botón", que se dice por estos barrios, utilizaré a mi perro como ejemplo. Habida cuenta de que ese parecido con la vida real ha de partir de unas premisas para poder considerarlo como objeto informatico, el ejemplo me sirve porque las cumple, en cambio no me sería válido porque cumple muchas más, que no tienen nada que ver, pero lo tomo de referencia:

- Herencia. O la capacidad que tiene de reproducirse. Por supuesto, aunque aún no lo ha demostrado (de lo que estoy muy seguro, porque es hembra) cumple esa particularidad: puede generar nuevos perros. Y de una forma más cercana a lo idílico, porque la herencia múltiple es innata, lo que no existe en algunos lenguajes orientados a objetos.

- Encapsulación. Sin lugar a dudas. Desde que nace y gracias al ADN, sabe mejor desenvolverse que un humano, luego tiene aprendidas ya una cantidad impresionante de cosas. Pero salvo que hagan un estudio del genoma (no sé si digo una burrada, no entiendo nada de eso) no es posible saber de qué forma tiene implantado ese aprendizaje. Visto desde fuera, son "cajas negras", o cápsulas de aprendizaje que no entendemos. Él tampoco. Las utiliza, empieza a mamar, a ponerse en pie y dar los primeros pasos, etc., pero el cómo, ni idea. Por lo tanto, nuevamente cumple con la segunda premisa, la encapsulación.

- Polimorfismo. Que será lo más lioso, probablemente. ¿Cómo se puede responder, sin romper los moldes anteriores, de distintas formas ante iguales o diferentes hechos o impulsos? Bueno, si hablamos solamente de mi perro es difícil, salvo que creemos herencias del mismo o veamos ancestros (antecesores, en el caso canino). De alguna manera podría no hacer falta esto, pero en la práctica sí, porque lo que vamos a hacer será crear uno o varios elementos diferenciadores. Supongamos que ladra cuando ve su comida (con la consiguiente denuncia del vecino de arriba), pero el perro de al lado, no ladra, quizás ni siquiera se la come porque no le gusta, y el tercero se la termina rápido y nadie se entera. ¿Podríamos hayar un vínculo común en estos tres comportamientos? Pues claro que si, probablemente más de uno: enseñanza, tipo de pienso o comida, apetito del perro, etc. y eso le hará comportarse de una forma u otra ante el mismo acontecimiento. Claro, ya no es un perro único, hablamos de otra cosa, y a esa otra cosa es la "Clase" TPerro. Algo muy similar y a la vez con sus peculiaridades.

Estos tres conceptos, explicados de esta forma tan abreviada, son los pilares en los que los intelectuales del tema están de acuerdo en que forman la programación a Objetos. La diferencia es que mientras para unos al parecer no hay más, para otros sí los hay, y yo creo (muy humildemente) que se debe a que estan absorviendo los restantes conceptos en los tres anteriores.

- Modularidad. Esta es una de mis dudas. Hay muchos autores que no la consideran como parte de la programación a objetos, cuando realmente, yo diría que es la más cercana a nosotros.

Supongo que si no se sabe, al menos se intuye con carácter general, qué es una aplicación modular, aunque la realidad es que tiene muchos enfoques. Y creo que se utiliza con mayor frecuencia justamente cuando no lo es. He oido más de una vez que un desarrollo era modular porque tenía módulos de contabilidad, facturación, almacenamiento, etc. que podían adquirirse e integrarse. Aplicaciones relativamente sencillas y acoplables. Pero eso no son módulos, al menos no lo son bajo el prisma que ahora nos interesa.

Si tenemos un desarrollo por resolver, amplio, complejo... normal. Es susceptible de ser dividido en partes, que contendrán su parcela de programación y de datos. Al menos lo es a nivel teórico y debería de serlo en un sentido práctico. Una vez conseguidas esas parcelas con vida propia, podemos hacer lo mismo con cada una de ellas, hasta conseguir algo hipotético en general, que serían muchos módulos (aquí bien dicho) con un carácter propio, en cuanto a codificación y datos. Esa es la "modularidad" que estamos tratanto.

Veremos que un concepto que parece teórico lo es sólo en la medida en que nosotros no lo recibamos "parcelado". Si nos llega un chorro de órdenes que suman 15.000 pues la modularidad es difícil que exista, pero ¿no es completamente distinto si recibimos muchas fracciones? Yo creo que sí. Y ¿Qué serían esas fracciones? Respuestas a actuaciones que un supuesto usuario realice o se prevea que puede realizar. Entonces la cosa ya varía, hay divisiones claras, no se mezcla la pulsación de una tecla con la elaboración de un impreso. Quizás una me lleve a la otra, pero en principio son eventos distintos y por lo tanto manipulables, y más por lo tanto, desglosables en zonas más pequeñas que son sus módulos. Acabo de utilizar una de las palabras "mágicas", repito: "...son eventos distintos..." o lo que es lo mismo, respuestas de módulos ante una acción generalmente provocada por el usuario, aunque no necesariamente.

- Quienes son más jóvenes en la programación, quizás no hayan pasado por la época eufórica de la programación estructurada, Berttini, Jackson, etc La realidad es que no me creo que haya habido un solo programador que siguiese sus pautas al pie de la letra, pero tuvieron su papel, y no carente de importancia.

Lo traigo ahora a colación por otro tema que prácticamente se basa en ello, es la Jerarquía. Es un concepto que está muy ligado con la herencia pero que se utiliza así, con nombre propio. Si miramos un término en la ayuda de cualquier lenguaje de este tipo, hablará de jerarquías, no de padres ni abuelos. Y adopta conceptos que han sido la base de la programación estructurada (que al fin y al cabo, se sigue utilizando al programar en lenguajes visuales

José Luis Freire