LA POO

¿Qué es la Programación Orientada a 

Objetos?

La P.O.O. (también conocida como O.O.P., por sus siglas en inglés) es lo que se conoce como un paradigma o modelo de programación. Esto significa que no es un lenguaje específico, o una tecnología, sino una forma de programar, una manera de plantearse la programación. No es la única (o necesariamente mejor o peor que otras), pero se ha constituido en una de las formas de programar más populares e incluso muchos de los lenguajes que usamos hoy día lo soportan o están diseñados bajo ese modelo (PHP, AS2, AS3,…).

Lo que caracteriza a la POO es que intenta llevar al mundo del código lo mismo que encontramos en El Mundo Real™. Cuando miramos a nuestro alrededor ¿qué vemos? pues, cosas, objetos, pero podemos reconocer estos objetos porque cada objeto pertenece a una clase, eso nos permite distinguir, por ejemplo, un perro de un auto (porque son de clases diferentes) y también un TV de otro (porque, aunque sean iguales, cada uno es un objeto distinto). Éste es el modelo que la POO intenta seguir para estructurar un sistema.

Es importante recalcar nuevamente que la POO no es un lenguaje de programación, es una forma de enfrentarse a ella. Esto significa que la POO le servirá para desarrollar en muchos de los lenguajes comunes de hoy en día (incluso en ASPuaj!) manteniendo un mismo esquema mental. Incluso le permitirá enfrentar otros proyectos que no necesariamente estén relacionados con escribir código…

Características de la P.O.O.:

No hay un acuerdo aceptado por todo el mundo respecto a cuáles son las características que definen la POO, pero al menos todos concuerdan en estas tres:

1. Abstracción.
2. Encapsulación.
3. Herencia.

Abstracción:

Cada vez que pronunciamos una palabra, realmente lo que hacemos es asociar ese sonido (o ese conjunto de garabatos al escribir) con una serie de cosas. Decimos que una ave es tal cosa, que una silla es tal otra, etc.

Cuando vamos a aplicar la POO, lo primero que debemos hacer es cumplir con una vieja máxima de guerra:Divide y Vencerás. Es decir, lo que hacemos es seccionar nuestro código en grupos de código más pequeño que, al unirlos, hacen el trabajo. Un buen ejemplo de abstracción es el cuerpo humano, aunque el cuerpo es una unidad, está dividido en lo que conocemos por sistemas (el sistema respiratorio, el sistema linfático, cardiovascular, etc., etc.). Estos sistemas, a su vez están compuestos por otros más pequeños: los órganos, y así sucesivamente. La abstracción nos permite dividir nuestro programa en distintos objetos que se agrupan para formar cosas más complejas.

Pero ¿qué demonios es realmente la abstracción? Básicamente es la capacidad de separar los elementos (al menos mentalmente) para poder verlos de forma singular. Como cuando describimos el cuerpo humano y decimos cabeza, brazo(s), pierna(s), etc.

Encapsulación:

También conocida como ocultamiento. Cuando me acuesto a ver televisión no me preocupo del modo como éste funciona, o lo que hace para cambiar de canal o aumentar el volumen. A menos que seas experto en electrónica o técnico en televisores, te pasará lo mismo: no lo sabes y no te importa; sólo sabes que al presionar un botón ocurre la magia.

La encapsulación se encarga de mantener ocultos los procesos internos que necesita para hacer lo que sea que haga, dándole al programador acceso sólo a lo que necesita. Esto da dos ventajas iniciales: Lo que hace el usuario puede ser controlado internamente (incluso sus errores), evitando que todo colapse por una intervenciónindeseada (tú no quieres que tu mamá, que no tiene ni idea de electrónica, abra tu televisor y empiece a jugar con los circuitos para cambiar los canales manualmente ¿verdad?). La segunda ventaja es que, al hacer que la mayor parte del código esté oculto, puedes hacer cambios y/o mejoras sin que eso afecte el modo como los usuarios van a utilizar tu código. Sólo tienes que mantener igual la forma de acceder a él (en el caso del control de la tele, que los botones sigan siendo los mismos y que el botón de “apagado” no cambie el volumen). Por cierto, estas puertas de acceso que das a los usuarios son lo que se conoce como interfaz.

Herencia:

Uno de los elementos (a mi modo de ver) más interesantes de la P.O.O. La herencia es la capacidad que tiene una clase de derivar las propiedades y métodos de otra (suena a chino ¿no? Calma, lo veremos luego con paciencia ). Tratemos de explicarlo con un ejemplo:

Decimos que una gallina es un ave; esto quiere decir que las gallinas tienen características comunes con otras aves (pico, plumas, etc.), es decir que la gallina hereda las características comunes de todas las aves. Pero además, resulta que un ave es un animal, lo que significa que también comparte características comunes al caballo, el perro, el hombre (seeee, somos animales) y cualquier otra cosa que pueda ser clasificada comoanimal.

La herencia nos permite, entre otras cosas, evitar tener que escribir el mismo código una y otra vez, puesto que al definir que una categoría (que en programación llamaremos clase) pertenece a otra, automáticamente estamos atribuyéndoles las características generales de la primera, sin tener que definirlas de nuevo.

Lenguaje Unificado de Modelado (UML)

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Diagrama de casos de uso:

un diagrama de casos de uso es una especie de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso.

Diagrama de clases:

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, orientados a objetos.

• Propiedad de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con las operaciones.

• El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica.

• Presenta las clases del sistema con sus relaciones estructurales y de herencia.

Diagrama de secuencia:

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso   permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Diagrama de secuencia:

Un diagrama de colaboración en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración, también llamados diagramas de comunicación, muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.

Diagrama de Estado:

Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. También ilustran qué eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones.

Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones.

Diagrama de Despliegue:

El Diagrama de Despliegue es un tipo de diagrama del lenguaje unificado de modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos también añadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre seran entre los nodos y por ejemplo con una base de datos.