La programación orientada a objetos (POO/OOP) es el paradigma de programación por excelencia en el mundo del desarrollo del software. Hoy día no se concibe el desarrollo de software sin él, y es necesario que tanto expertos como neófitos en programación utilicen de forma adecuada y ESTRICTA la terminología asociada, para poder formular ideas y planteamientos en común sin mal entendidos.

No hace falta saber programar para entender y hablar de objetos.

[sociallocker]
 

Historia breve

Antiguamente, los programas no eran más que una sucesión en serie de instrucciones que se ejecutaban una a una (programación lineal).

Con el avance de la complejidad de las soluciones, aparecieron estructuras de control que permitían que la ejecución pudiera saltar de una linea distinta a otra sin seguir el flujo en serie. Aparecieron instrucciones como GOTO, IF/ELSE, WHILE/UNTIL, etc.

Con estas nuevas estructuras de control, apareció la denominada PROGRAMACIÓN MODULAR. Ésta se diferenciaba de la programación lineal en que el software se segmentaba en modulos o procedimientos, cada uno con una función específica.

Así, existía un módulo o procedimiento principal (o MAIN), y una serie de módulos complementarios que eran llamados por el módulo principal. Los módulos complementarios se ejecutaban y al acabar devolvían el control a la siguiente linea del procedimiento MAIN. A estos módulos se les conocía como procedimientos, funciones o subrutinas.

El mayor problema de este paradigma es que, a medida que crecía la complejidad del software, el número de funciones y llamadas a éstos crecía hasta un punto que hacía difícil el seguimiento de la ejecución, o dicho de otra forma, la TRAZABILIDAD del software, y por tanto dificultaba la depuración, el mantenimiento y su mejora. El código saltaba continuamente de una sección a otra, llegando a ser imposible seguir el programa. Es por eso que muchos programadores puritanos declaran su aversión al uso del GOTO.

Con la POO, todo esto cambió, y se generó un nuevo paradigma que cambió completamente la forma de analizar y resolver los problemas. En POO, existe un procedimiento principal o MAIN pero, a partir de él, se crean objetos que cumplen una funcionalidad y que, a la vista del desarrollador, son entes autónomos, inteligentes y, muy especialmente, fáciles de entender semánticamente. La POO marcó un antes y un después en la trazabilidad del software.

¿Qué es un objeto y una clase?

Un objeto en la vida real es algo que sabemos identificar. Le ponemos un nombre y reconocemos sus propiedades y funciones.

Por ejemplo, un coche es un objeto. Un coche puede ser de marca Citroen, Mercedes o SEAT, y a su vez puede ser de color rojo, verde, azul…

Todos los coches, por lo general, son capaces de las mismas acciones: acelerar, frenar, girar, marcha atrás, encender/apagar luces, claxon…

Todos los coches pueden ser y actuar de maneras diferentes, ser de distinto color o tener más caballos de potencia para acelerar más rápido, pero tienen todos en común que son eso mismo: coches.

Son sus propiedades los que diferencian a unos coches de otros, pero en resumidas cuentas, son todos OBJETOS de la CLASE coche.

Por tanto, una CLASE es lo que define qué es un coche, sus propiedades y capacidades. Es un concepto abstracto, mientras que un OBJETO es la instanciación de una clase, un ente que define las propiedades específicas que lo diferencian de otro objeto de la misma clase.

Propiedades

Propiedades de un coche son el color, la marca, el modelo, la velocidad punta, número de marchas, asientos o plazas, etc.

Llamamos PROPIEDAD a un elemento de una clase que puede definir una característica del objeto, y que es compartida por todos los objetos de esa clase, aunque su valor no sea igual para cada objeto.

No todos los coches han de ser de color rojo, pero todos los coches tienen una propiedad llamada color. La propiedad color es común en todos los coches, aunque para cada uno tenga un valor diferente.

Algunas propiedades pueden ser de lectura y escritura, y otras sólo de lectura. Por ejemplo, podemos cambiar el color de nuestro coche rojo a azul, esto es una propiedad de lectura y escritura (podemos leer o ver su color actual, y cambiarlo). Pero la marca de un coche es una propiedad de sólo lectura (por mucho que cambiemos el color, un SEAT seguirá siendo un SEAT y no podremos cambiar este triste hecho). La ACCESIBILIDAD de una propiedad es definir si se puede leer, escribir o ambas cosas. Define lo que podemos leer y tocar en los objetos de una clase.

Métodos

Decíamos antes que los objetos de la clase coche disponen de propiedades que los diferencian de otros objetos de la misma clase, pero además, los coches pueden hacer cosas, más allá de dejarse pintar.

Un coche puede arrancar el motor. La acción de arrancar el motor es un MÉTODO. Un método se diferencia de una propiedad en que hace algo, mientras la propiedad no hace nada, sólo almacena un valor para la propiedad. Un método es, básicamente, una función, un procedimiento, una subrutina, una porción de código definido dentro de la clase coche que ejecuta las instrucciones necesarias
para arrancar nuestro coche.

Las propiedades de una clase pueden determinar el comportamiento de sus métodos. Un coche no podrá arrancar si su propiedad Gasolina es igual a 0. Podremos llamar igualmente al método Arrancar, pero tal método acabará prematuramente.

Asímismo, las llamadas a métodos pueden influir en las propiedades del objeto. De este modo, cuando arrancamos el coche, puede que su propiedad Arrancado cambie su valor a ‘verdadero’ (si tenemos gasolina, claro).

Igualmente, los métodos son comunes entre objetos de la misma clase; todos los coches arrancan antes de moverse. Otros métodos pueden ser acelerar, tocar el claxon, o frenar. Todos objetos de la clase coche soportan estos métodos.

Eventos

¿Qué pasa si marchamos con nuestro coche 1000 km y continuamos sin repostar? Tarde o temprano el nivel de gasolina quedará reducido a 0. Si eso es así, el coche no podrá continuar la marcha.

Un evento es un acontecimiento definido claramente, que el objeto nos comunica para hacernos saber que se encuentra bajo esa condición. Por ejemplo, en el caso anterior, el coche puede disparar el evento RESERVA cuando el nivel de gasolina sea inferior al 5%. Es responsabilidad del coche saber cuándo es el momento de avisar que estamos en reserva, y notificar esa situación, pero a partir de aquí, el coche no hace nada más. Los coches no repostan solos, ni introducen la manguera en el depósito, eso es tarea del conductor.

En un programa, un coche puede ser definido como clase e instanciado como objeto. Después podemos invocar o llamar al método Arrancar para iniciar la marcha, y continuarla de forma indefinida hasta que el objeto coche nos notifique mediante un evento que ya está en nivel de reserva. En ese momento, es el programa que creó al objeto (el conductor) el que debe recibir ese evento y actuar en consecuencia, posiblemente invocando los métodos Detener y Repostar (no olvidéis ApagarLuces!).

Los coches saben que cuando se les invoca su método Repostar, su nivel de Gasolina se restaura a 100%. Los objetos son inteligentes en su ámbito, saben lo que tienen que hacer con ellos mismos, pero se desentienden de lo que haya que hacer fuera de ellos. Son los eventos que un coche soporta los que permiten a otros objetos conocer su situación e interactuar. Los eventos son, en gran medida, mensajes.

Estos eventos o mensajes han de ser escuchados. El conductor debe recordar que hay que antender el indicador de reserva cuando este se enciende. Si un conductor no vigila este nivel, cuando se llegue a reserva el coche disparará el evento de Reserva, pero si el conductor no está atento a él, no ocurrirá nada más. El coche ha notificado su situación correctamente, y hasta ahí llega su alcance.

Estar o no atentos a ciertos eventos como Reserva o Calentamiento del motor excesivo es lo que denominamos subscribirse a un evento. Un programa u objeto podrá recibir eventos/mensajes de otro objeto sólo y sólo si está subscrito a dicho evento. Si no lo está, el evento se disparará igualmente cuando tenga que ocurrir (el coche va a encender la luz de reserva, la veamos o no, es su obligación o alcance).

Resumen

Un clase define cómo son los objetos de esa clase. Las clases definen propiedades, métodos y eventos. Estas 3 columnas son las que definen a una clase.

¿Por qué lo hacemos así?

Trabajar con POO y objetos es una ventaja importante, pues nos permite muchas facilidades.

Con programación modular, cada coche distinto era una subrutina distinta. Con POO definimos la clase coche una sola vez, y todos los objetos coche que instanciemos seguirán ese esquema, aunque sean completamente diferentes entre sí. Y si en algún momento queremos cambiar cómo arrancan los coches, bastará con cambiar el método Arrancar de la clase, y todos los objetos de esa clase arrancarán de esta nueva manera, sin tener que cambiar el código en nada más que un solo lugar.

Reutilización

Normalmente, una clase se define en un fichero. Todo lo que un coche haga estará definido en ese fichero, así que mantener, mejorar o cambiar coches es muy fácil, sabemos que todo lo que concierne a coches estará definido en el fichero donde se describe la clase coche. Esto permite una gran ventaja, la REUTILIZACIÓN. Una clase coche en un programa puede servirnos en otro programa, y se comportará igual. Podemos compartir con otros programadores nuestra clase coche, y se comportarán igual, a menos que quiera modificar la clase ellos  mismos.

Encapsulación

No nos importa qué hace un coche por dentro. Cuando giramos la llave, queremos que arranque, no nos importa cómo lo haga por dentro, no vamos a mirar las válvulas moverse. Los coches arrancan, y es lo que necesitamos saber. Tratamos al objeto coche como una caja negra que oculta lo que ocurre dentro. Sólo nos importa el resultado, no cómo lo haga. A esta forma de plantear los objetos como entes autónomos de caja negra lo llamamos ENCAPSULACIÓN. El código del objeto está encapsulado y sólo se expone al conductor mediante propiedades,
métodos y eventos. Todo lo demás que pueda existir dentro de una clase, y que no sea una propiedad, un método o un evento no nos importa, forma parte de las interioridades de un coche. El coche es un objeto encapsulado que se utiliza para que lo lleve a casa. Al dueño no le importa cómo lo hace para que las ruedas giren hasta llevar su culo a casa. Sólo le importa el resultado, y sólo llevara la clase coche al taller cuando se manifieste un error en la clase que requiera cambiar sus tripas. Una vez la clase coche ha sido definida y bien programada, es un coche, y ya está, sabemos lo que esperar de él, y él sabe lo que tiene que hacer.

Herencia

Otro concepto es la HERENCIA. La herencia es un proceso mediante el cual una nueva clase que creamos puede heredar las propiedades, métodos y eventos de otra clase si así lo queremos. Cuando creamos la clase Todoterreno, y establecemos que hereda de la clase Coche, automáticamente la clase Todoterreno dispondrá de las mismas propiedades, métodos y eventos que tenía la clase Coche, sin necesitar hacer nada más. No hace falta definir de nuevo esos elementos, porque ya están definidos en la clase Coche. Un objeto de la clase Todoterreno arrancará y notificará nivel de reserva como cualquier otro objeto de la clase coche.

Ahora bien, nuestra clase Todoterreno hace algo que no hace la clase Coche: podemos pasar a modo tracción 4×4. Éste es un método especial de la clase Todoterreno que sí hay que definir para esta clase. Así la herencia permite crear fácilmente clases a partir de otras clases y añadir (o eliminar o cambiar) elementos que los diferencian de la clase de la cual heredan.

***

(Autor del original de este artículo: Fermín Vallecillos)
[/sociallocker]