What the Hell is “This”?

Después de escribir sobre el ámbito, me quedó en la mente la pregunta ¿por qué no hablaste del bendito “this”, que trae a todos los programadores que comienzan (y algunos que ya llevan tiempo) por el valle de la amargura? Así que, como no quería editar el post, preferí hacer uno nuevo.
Comencemos por el Principio:

¿Qué es “this”?

Pues simple, “this” es una palabra reservada en la mayoría de lenguajes de programación que tiene la particularidad de significar cosas diferentes según donde se encuentre. Es conocida también como una propiedad contextual.
¿Cómo es eso? La mejor forma que he encontrado para explicarlo es traduciéndolo al castellano. “This” significa “esto”.
Entonces, la particularidad de “esto” (que, si recuerdan un poco sus clases de castellano -cosa que seguro no pasará- es lo que se conoce como un adjetivo indicativo o determinativo (uhhhh, muy técnico o_Ô)).
En un sentido más llano, la palabra “esto” se refiere siempre a algo que está cerca, pero puede cambiar según el contexto.
Si estoy en esta habitación y digo “esto”, está claro a lo que me refiero (esta habitación), pero si salgo de ella y digo “esto” estoy hablando de algo completamente diferente… Es decir que lo que significa la palabra esto cambia dependiendo de donde me encuentre.
Exactamente lo mismo es lo que ocurre con this; su significado varía, dependiendo a donde se escriba.
Si estoy dentro de una clase, la referencia de this será esa clase, si estoy en un movieclip, en Flash, this se refiere a ese movieclip.
Es precisamente esta versatilidad de this la que causa grandes dolores de cabeza a muchos programadores, sobre todo cuando estamos comenzando, nos hallamos un poco perdidos cuando encontramos clases llenas de ella por todas partes y no entendemos de qué va.
Pues, la forma de resolver esa duda se basa en comprender el contexto donde la propiedad aparece (si es una clase, una instancia, una función…). Una vez que se comprende el contexto, se entiende fácilmente de qué se trata. Algo así como “para entender esto tienes que mirar alrededor”.
Así que, no tengan miedo de usarla. Bien usada es una poderosa herramienta que puede sacarlos de problemas y regalarles a cambio un código más limpio y más efectivo.

programación, desarrollo, this

Programación Orientada a Objetos – Ámbito, Public, Private, Protected, Local

Este post es parte de una serie de artículos sobre POO y viene a continuación de Sub Clases (II)

Bien, los temas que vamos a tratar en esta ocasión son tan básicos que posiblemente alguno piense ¿y por qué no hablamos de esto al principio? Y la respuesta lógica es: porque no lo habríamos entendido correctamente.
El tema que vamos a tratar ahora es uno de los mayores dolores de cabeza cuando se comienza con la programación -y más aún con la programación orientada a objetos-, muchos problemas en el código suelen estar asociados con algún error a nivel de ámbito, así que comencemos por allí:

¿Qué es el Ámbito y Cómo Afecta mi Vida Sexual?

Cuando hablamos de ámbito o alcance nos estamos refiriendo principalmente al área de influencia de una variable o función, a la zona donde ésta tiene sentido.

Toda variable/función tiene un rango de acción, se encuentra en un sitio, tiene un contexto, fuera del cual pierde significado y valor. Un ejemplo que puede ilustrar esto puede ser un lámpara. La lámpara, al encenderla, ilumina un área específica, pero no tiene influencia fuera de esa área. Por ejemplo: si necesito buscar algo en mi cuarto, que la luz de la sala o de la cocina estén encendidas sería irrelevante para mí porque mi cuarto está fuera del área que ellas iluminan, pero si enciendo la luz de mi cuarto puedo buscar lo que necesito más claramente, aunque no tendría ninguna influencia fuera de él, él ámbito (alcance) de esa luz se limita a mi cuarto.

De acuerdo con su ámbito una variable/función puede ser:

• Pública
• Privada
• Protegida
• Local

Vamos a hablar de estos ámbitos desde el punto de vista de la clase.

Public:

Una variable/función pública puede ser accedida desde fuera de la clase. Es decir, puedo acceder desde la instancia de la clase y no sólo desde el código interno de la clase. Ejemplo de funciones públicas son los métodos de una clase. También es posible crear variables públicas, para que puedan ser manejadas desde la instancia, pero no es algo común o recomendable, entre otras cosas porque deja un hueco de seguridad en la clase, acabando con la idea de la “encapsulación”. Para declarar una variable/función como pública, se le antepone la palabra clave “public”.

Private:

Al contrario que las públicas, las variables/funciones privadas sólo pueden ser accedidas desde dentro de la misma clase. Todo intento de llamarlas desde la una instancia de la misma es en vano. Mantener variables/funciones privadas permiten tener un mayor control sobre la clase, sobre el modo como procesa sus métodos, como maneja sus variables, etc. Para declarar una variable/función como privada, se le antepone la palabra clave “private”.

Protected:

Existe un tipo intermedio de ámbito, llamado “protegido”. Es un punto medio entre público y privado, porque -como ocurre con las privadas- no se puede acceder a ella desde una instancia de la clase, pero -como ocurre con las públicas- puede ser accedido desde las subclases de ésta, no importa si se encuentran o no en el mismo paquete. Básicamente significa que, si una clase hereda de otra, tendrá acceso a las variables/funciones protegidas de la super-clase, de lo contrario, no podrá acceder a ellas. Para declarar una variable como protegida, se le antepone la palabra clave “protected”.

Local:

Una variable “local” sólo es accesible desde dentro de la función donde se declara; esto es válido tanto para los parámetros de la función como para las variables declaradas dentro de ella. Una vez terminada la función, la variable es destruida hasta que la función vuelve a ser invocada. No hay palabras clave para las variables locales.

¿Cómo Afecta esto mi Vida Sexual?

Como dije, una buena parte de los problemas que la gente suele tener al trabajar con clases es comprender cómo funcionan los ámbitos, cómo acceder a funciones/propiedades/variables y como permitir a otros que accedan a las nuestras; por lo tanto, entender esto significa perder menos horas depurando código, lo que significa menos tiempo programando, lo que es igual a menos frustración por falta de tiempo para el sexo. Además a las chicas les encantan los buenos programadadores

Tags Technorati: POO, Programación Orientada a Objetos, Clases, Sub Clases, Ámbito

Programación Orientada a Objetos – Sub Clases

Después de un largo tiempo, volvemos a las andadas con la POO.
Este post es parte de una serie de artículos sobre POO y viene a continuación de Clases Dinámicas y Clases Estáticas

Si revisan nuestro segundo post de POO: Características de la P.O.O., recordarán que, entre ellas, comentábamos acerca de la herencia, diciendo que:

La herencia es la capacidad que tiene una clase de derivar las propiedades y métodos de otra.

Dicho de otra forma. La herencia se asegura de que una clase, al derivar de otra, tenga las mismas cualidades de la clase de la que proviene, además de las que sean propias de la misma clase.
Ocurre lo mismo que con los seres vivos, los animales heredamos de nuestros padres características como tipo, color de piel, capacidades para desarrollar ciertas destrezas, etc. Sin embargo, también tenemos cualidades que nos son propias y que nuestros padres no poseen, como la propia identidad, los gustos propios, etc.
En la POO, una clase que deriva de otra es conocida como sub-clase, y aquella de la que proviene se conoce como super-clase. Viéndolo de un modo gráfico, sería algo como esto:

En principio, tenemos una super clase llamada Animal, que contiene todos los elementos generales que tiene todo animal (como alimentación, piel, reproducción, etc.). De esta super-clase, se derivan toda una serie de clases, que corresponden a los distintos tipos de animales que existen. Todos ellos tienen una conexión directa de la clase Animal, puesto que provienen de ella, son sub-clases de Animal.
Sin embargo, hay dos cosas que debemos tener en cuenta: 1. No todas comparten las mismas características de la clase animal (así Hombre tiene boca, The Parrot™ tiene pico, mientras Perro y Gato tienen hocico). 2. A pesar de que tienen relación indirecta (porque todas pertenecen a la misma super-clase), eso no implica que deba haber una relación directa entre las sub-clases. Es lo mismo que ocurre con nuestros padres y hermanos.

Super Clase y Sub Clase:

Una cosa que debemos tener clara a la hora de meternos en las lides de la herencia es que no existe propiamente un tipo de clase llamado sub-clase o super-clase. Estos conceptos se utilizan para definir la relación que existe entre dos clases concretas. Una sub-clase es simplemente la que hereda de otra clase, a la que llamaremos super-clase; dicho de otro modo, la super-clase es la clase madre y la sub clase la clase hija. Igual como ocurre en el resto de las relaciones, nuestra sub-clase puede ser al mismo tiempo una super-clase para otras clases, y así sucesivamente. Esto es algo que veremos muy comúnmente en la POO donde, por ejemplo, todas las clases derivan, en algún punto de la clase Object.

¿Para qué Sirven las Sub-Clases?

Si no ha quedado claro hasta ahora, vamos a repetirlo de modo sencillo y directo. Crear sub-clases nos permite crear una nueva clase personalizada, tomando los elementos que necesitamos de una clase ya creada. De este modo, no tenemos que volver a escribir todas las propiedades, métodos y eventos que ya tiene la clase que hemos tomado como base, sino que podemos utilizarlos directamente, reinterpretarlos o incluso ocultarlos para que no puedan ser accedidos desde afuera de la clase. Por ejemplo, quizá te interese que pueda cambiarse la altura de la instancia, pero no quieres que pueda cambiarse el ancho, aunque un uso más común es darle a nuestra nueva clase ciertas características que no existen en la super-clase, manteniendo las que ya tenemos en ella, o también para hacer ciertos cambios en la super-clase. Es lo que se conoce como extender una clase y es por ello que la palabra para crear una sub-clase es extends.

Wow! esto ha sido largo. Así que dejaremos hasta acá esta parte y en el siguiente post hablaremos de cómo crear una sub-clase y otras cosas importantes como sobre-escritura de métodos y cómo acceder a la super clase desde una sub-clase.
Tags Technorati: POO, Programación Orientada a Objetos, Clases, Sub Clases

Programación Orientada a Objetos – Eventos (I)

Este post es parte de una serie de artículos sobre POO y viene a continuación de Cómo Escribir Una Clase

Nota: Este post está dedicado al autor de cierto curso fracasado de Ruby on Rails, nuestro estimado Auyama, el Hideki pervertido U_U

Bien, en el post anterior habíamos visto como se estructura una clase, dejando el tema de los eventos para un post aparte. La razón de esto es que el asunto de los eventos requiere una atención especial.

Los eventos son el medio como interactúa una clase con otras o con el propio usuario, se encargan de avisar que algo ha ocurrido y de manejarlo de una forma o de otra. Cada vez que escribimos con nuestro teclado, que hacemos click en un botón o un link, que cambiamos el tamaño de un objeto, estamos generando eventos. Es por ello que, cuando programamos, debemos tener en cuenta la posibilidad (no siempre necesaria, pero lo será a medida que generemos clases cada vez más complejas), tanto de manejar eventos que sólo implican a nuestra clase como de generar nuestros propios eventos, de modo que los usuarios de nuestras clases (en principio nosotros mismos) puedan decidir cómo reaccionará su código ante ellos.
El modo de manejar los eventos en P.O.O. se conoce como emisor/receptor, también llamado despachador/escuchador o simplemente dispatcher/listener.
En esta dupla, la primera parte (el emisor) se encargará de lanzar el evento, mientras la segunda se encargará de recibirlo y gestionarlo como sea necesario. La primera parte será responsabilidad nuestra (los programadores de la clase) y la segunda es responsabilidad de quien utiliza la clase (en principio, también nosotros).
Cada lenguaje tiene su propio manejador de eventos, que es el que nos permite, tanto lanzar los eventos como crear los receptores (escuchadores/listeners) que nos permitirán manejarlos. Realmente es una aplicación del patrón Observer, del que hablaremos más adelante, cuando hablemos de patrones, pero que necesariamente tocaremos en este post.

¿En qué consiste la emisión/recepción de eventos?

Básicamente, de lo que se trata es de avisar (en principio sin importar si alguien escucha o no) de algún cambio en el estado de la instancia, que puede ser un click en el objeto, el final de un proceso de carga o la terminación de algún complejo proceso. Cada vez que el evento en cuestión ocurre, la instancia dirá “¡¡Hey, me ocurrió este evento!!”. Esto es lo que conocemos como broadcasting.
Aquí es donde entra en juego el (los) receptor(es). Éste se encargará de estar atento, de escuchar (de ahí que se les llame listeners) el(los) evento(s) que ocurra en el emisor, y responderá adecuadamente.

Para ejecutar esto correctamente, es necesario disponer de una clase que se encargue del manejo de los eventos, tanto de la emisión como de la recepción de los mismos, un eventHandler; ésta puede ser dada por el mismo lenguaje (por ejemplo, el eventDispatcher en AS) o creada por el propio programador. Veamos un ejemplo de uso en AS2:

Technorati Tags: Programación Orientada a Objetos, Clases, Action Script

Programación Orientada a Objetos – Eventos (II)

Este post es parte de una serie de artículos sobre POO y viene a continuación de Eventos (I)

Despacho (emisión) de Eventos

En este caso, haremos una pequeña adaptación de la clase que habíamos creado al principio, para lanzar un evento cada vez que la persona cumple años.

Bien, lo que hemos hecho es agregar, a nuestra clase Persona, un Despachador de Eventos, también le pedimos que , cada vez que se ejecute el método cumpleanhos, lance un evento, que hemos llamado onBirthday.
Para ello, hemos hecho lo siguiente:

1. Importamos la clase EventDispatcher, que es una clase estática, por lo que no hace falta instanciarla (más adelante hablaremos de las clases estáticas).
2. La clase EventDispatcher requiere que declaremos tres funciones: addEventListener, removeEventListener y dispatchEvent. Luego veremos para qué se utilizan.
3. En el constructor de la clase, inicializamos el Despachador (EventDispatcher.initialize(this)).
4. Para lanzar un evento, utilizamos en médoto dispatchEvent, que requiere un objeto con dos propiedades: target, que será el objeto que lanzó el evento, y type, que será el nombre del evento en sí.

Recepción (escucha) de Eventos

Bien, ya sabemos cómo despachar un evento (broadcasting). Ahora veamos cómo podemos capturar ese evento y manejarlo, ya sea en otra clase o en otra parte de nuestro código:

1. En nuestro ejemplo, hemos creado dos nuevas personas: auyamaApesta (hola Aoyama ) y theParrot (no sé cuál de los dos es más persona, pero igual servirán). Por supuesto, como ambas son instancias de la clase Persona, ambas pueden lanzar el evento onBirthday que creamos anteriormente.
2. Además, hemos creado también un nuevo objeto, myListener, que será el encargado de recibir y manejar el evento.
3. A través del método addEventListener, asociamos el objeto myListener a las instancias que hemos creado. Para ello le decimos: a.- El Evento que queremos recibir (en nuestro ejemplo, onBirthday) y; b.- El objeto que lo manejará (myListener)
4. Programamos, en el receptor (myListener) la función que deseamos manejar (onBirthday).

Este último punto requiere especial atención. Si nos fijamos, veremos que la función onBirthday recibe como parámetro un objeto (evt), que es el que enviamos en el EventDispatcher. Este objeto contiene dos propiedades: la primera es la propiedad target, que se refiere al elemento que envía el evento (en este caso, la instancia) y type, que nos dice el nombre del evento. Es por ello que al colocar evt.target.edad, nos estaremos refiriendo a la propiedad edad de la instancia en cuestión, igualmente con el nombre.
Otra cosa a tener en cuenta es que hemos creado un sólo listener que escuchará a las dos instancias, de modo que, en cada caso, responderá a cualquiera de las dos que lance el evento. Igualmente, es posible asociar varios objetos como listeners de un mismo evento, lo que nos permite hacer que un evento genere una serie de acciones diferentes al mismo tiempo.

Bueno, sabía que esto iba a ser largo. Creo que con esto tienen para entrenerse un rato. En nuestro próximo post hablaremos acerca de las Clases Estáticas.

Technorati Tags: Programación Orientada a Objetos, Clases, Action Script