Programación Orientada a Objetos - Clases Dinámicas y Clases Estáticas

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

Bien, hemos llegado lejos -al menos más lejos de lo que pensé en un principio- y hasta ahora hemos establecido las bases para entender de qué se trata todo esto de la Programación Orientada a Objetos y cómo escribir y usar nuestras clases. Lo que haremos a partir de ese punto será concentrarnos más en ciertos detalles relativos a la creación y utilización de las clases, que nos permita que nuestros proyectos sean más eficientes y flexibles para, entre otras cosas, vernos en la necesidad de tener que modificar una clase cada vez que vamos a usarla en un nuevo proyecto (algo que es muy común cuando se comienza a programar con ellas) y hallar la forma de tener un mejor control de nuestro código sin que ello sea un dolor de cabeza a la hora de usarlas en distintos proyectos.
En este post, nos concentraremos en averiguar cuáles son los tipos de clases que existen y cuál es la utilidad de cada uno. Por eso, antes de comenzar, quiero hacer una aclaratoria para no confundirnos a causa del título. Existen tres tipos básicos de clases: cerradas, dinámicas y estáticas.
La razón por la que no hablaremos del primer tipo es porque ya lo conocemos (O RLY?). Sí, las clases que hemos estado programando hasta ahora se conocen como clases cerradas, es decir, todos los eventos, métodos y propiedades están definidas dentro de la clase, así que no es posible agregárselos dinámicamente.

Clases Dinámicas

En oposición a las clases cerradas existe los que se conoce como clases dinámicas. Su principal característica es que permiten agregar en tiempo de ejecución, propiedades y métodos a la clase, es decir, que yo puedo agregar una nueva propiedad a la instancia de mi clase, aunque ésta no haya sido definida originalmente. Veámoslo con un ejemplo comparativo:

Como puedes ver, la única diferencia entre Persona y Persona2 es que en el segundo caso hemos agregado, en la declaración de la clase, la palabra clave dynamic. Esta palabrita es la que hará toda la magia, ya que, como puedes ver en la implementación (más abajo, en la imagen), la instancia de Persona nos dará un error en tiempo de compilación (diciéndonos que la clase Persona no tiene una propiedad llamada apellido), mientras que Persona2 simplemente creará la nueva propiedad (fíjate que no existe en la clase) y le colocará el valor correspondiente.
De hecho, si has trabajado con AS2 (que supongo que así es), posiblemente esto sea algo que has implementado varias veces.
En cualquier caso, no es recomendable usar clases dinámicas a menos que sea necesario, porque entre otras cosas, la verificación de datos es menos estricta que en las clases cerradas, lo que hace que se pierda control sobre los datos de la clase, haciéndola suceptible de errores inesperados.

Clases Estáticas

Por su parte, las clases estáticas están pensadas para contener elementos (propiedades o métodos) que no dependen directamente de un objeto para su funcionamiento ¿Cómo es eso? Veamos:
En varias ocasiones nos encontramos conque tenemos una función que puede ser utilizada por distintos objetos, o en diferentes situaciones, que no están relacionadas con algún objeto específico, puede ser el caso de una operación matemática, un cálculo, dibujar una forma geométrica, etc. Sin las clases estáticas la opción sería: Crear esta misma función en cada clase que utilizamos (copiar y pegar no es reusabilidad). Pero esto es algo engorroso y poco práctico (¿qué pasa si queremos agregar un nuevo parámetro a nuestra función o conseguimos una forma más efectiva de hacer lo mismo? Tendríamos que reescribir el código en cada clase donde lo hemos usado… y tú no quieres hacer eso ¿verdad?).
Un buen ejemplo de clases estáticas es la clase Math, común en ActionScript, Java, .Net, etc. Esta clase se encarga de hacer una serie de operaciones matemáticas a las que sólo les pasamos los parámetros que necesita. Otro ejemplo típico sería una clase que se encargara de dibujar objetos. Es la que veremos en este ejemplo:

En este caso, tenemos una clase que contiene un sólo método (getSolidRectangle), que además es de tipo estático (lo sabemos por el uso de la palabra clave static en la declaración del método) y que dibuja un rectángulo con color de fondo sólido en un mc que hemos enviado como primer parámetro.
Si nos fijamos en la implementación de la clase, veremos que sólo tiene tres líneas:

1. Importa la clase.
2. Crea el movieclip donde dibujaremos el rectángulo.
3. Llamamos al método getSolidRectangle para dibujar el rectángulo en cuestión

Como te habrás dado cuenta, en este caso no hemos creado una instancia de Graph (que lo haríamos con la palabra clave new). Esto se debe a que las clases estáticas no se instancian (o sea, que no podemos crear objetos a partir de ellas), sino que podemos usar directamente sus elementos, simplemente apuntando a al clase misma (Graph.getSolidRectangle()). Si alguna vez has usado la clase Math sabes de lo que estoy hablando.
Es por eso que las clases estáticas normalmente son utilizadas para albergar esos procedimientos que queremos reutilizar una y otra vez, pero que no están directamente asociados a un objeto o una clase en particular. Así, en vez de tener que escribir una y otra vez el mismo procedimiento, sólo tenemos que importar la clase y usarla. Si luego queremos hacer cambios en el(los) procedimiento(s), hacemos los cambios en la clase estática y estos se actualizarán automáticamente en todos los sitios donde se utilice. Esto sí es reusabilidad
Un dato importante, cuando creamos una clase estática, todos los elementos públicos de dicha clase también deben ser estáticos.

Bien, creo que hasta acá estará bien de momento. En el próximo post hablaremos de Sub-Clases.

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

Aprendiendo JQuery

Por lo general, no soy dado a lanzarme al primer framework que consigo. De hecho, suelo ser un poco renuente a ello, por varias razones. La primera y principal es que me gusta aprender las cosas desde su base, y un framework, a fin de cuentas hace que te saltes ese paso (es por la misma razón por la que “aprendí” HTML, XHTML, CSS, XML con el siempre amado bloc de notas o en algún editor, como Dreamweaver, desde la vista de código). Ya lo he dicho antes, me gusta aprender, me gusta tener un reto que perseguir, y en ese sentido, no me llevo bien con la idea de recibir todo ya masticado (eso es lo que hace que cuando tienes un problema termines más perdido que Adán el día de las Madres ).
También es que, hasta ahora, no he tenido alguna necesidad que justifique cargar nosécuantos kb de líbrerías para poder hacer algo, y mis escasos conocimientos de js (para el caso) me han venido bastante bien y mucho más ligeros. Claro que muchos dirán que con las conexiones de hoy día, unos cuantos kb no serán una gran diferencia, pero, como decía aNieto

En definitiva, cargamos mucho el tiempo de carga de nuestra página. Es cierto que con las conexiones de hoy en día 100kb no son nada, pero imaginar una web como Microsiervos con una web de 100kb la cantidad de información que debe estar transmitiendo por minuto.Esto obliga a tener que buscar servicios con mayor ancho de banda, con su consecuente aumente de precio.

El asunto es que, para un proyecto que tuve que hacer, necesitaba crear una galería simple, y (que siempre pasa con las entregas), no tenía tiempo de crear una, así que decidí apelar al súper conocido y muy elegante Lightbox2, que me vino perfecto para lo que necesitaba, pero tiene (en mi humilde opinión), dos problemas:

1. Necesita 3 librerías diferentes para trabajar
2. La necesidad de colocar el atributo “rel” en cada link donde vas a trabajar. Si no lo necesitas puede valer ¿pero y si lo necesitas, o si la cantidad de imágenes convierte a ese simple paso en un fastidioso y largo dolor de cabeza?

Luego ocurrió que, debido a la distribución de los textos, pensé que le vendría bien usar un efecto acordeón, lo que implica, tomar las librerías (prototype, scriptacoulus, effects), aprenderlas y hacer las modificaciones necesarias para crear el dichoso efecto… mucho trabajo para poco tiempo.
Fue así que recordé que había visto en una de mis búsquedas por San Google, que había un plugin de jQuery, que imita el Ligthbox, así que me puse a buscar y me encontré el jQuery Lightbox Plugin, creado por Leandro Vieira. Aún no lo implemento, pero después de leer un poco sobre el tema, decidí usar jQuery para mi aplicación, hacer así ambos efectos que quería con la misma librería y ponerme a estudiar de una vez jQuery, que sé que me hará falta en algún momento.
Claro, hasta aquí puedes decir Bueno, ¿y a mí que me importa que quieras aprender jQuery? Yo también quiero y no lo ando publicando. Pues, que, como hago con las cosas que voy descubriendo, quería compartir con uds. este descubrimiento (nuevo para mí, que ya vendrá fael a darme un lindo faelazo) y que, además, iré escribiendo algunos tips en la medida que vaya aprendiendo y haciendo cosas con él (que no, no será un nuevo curso, que ya tengo bastante con el de POO ¬¬).
Así que, más material para uds. y más trabajo para mí. Ahí nos veremos.

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

De Vuelta al Blog

---

Sí, sé que muchos pensarán que he tenido el blog olvidado, que parece que ya se murió y tal. No es así.
Me gustaría decir que me fui de vacaciones a Fiji o algo así y que estoy pasándola muy bien como para ponerme a escribir sobre programación o sobre diseño y esas cosas que la gente cree que yo sé; pero lamentablemente no es así.
Lo que me ha tenido tan alejado ha sido un proyecto relativamente fácil de hacer, pero muy mal manejado, y como no es propiamente mío me ha tocado bailar con la más fea, haciendo cambios cada dos por tres, cada vez que al cliente se le ocurría alguna brillante idea. Hasta que, por fin, hoy mismo, ha sido publicado y he tenido que llamar a mi amigo -el que consiguió al cliente- para decirle que ya estaba bien de hacer cambios por nada. Para bien o para mal, esto para mí no es sólo una pasión, también es un negocio y de él vivo. Yo puedo regalar mi dinero, pero no el de mi familia, así que ya está.
Bueno, aún hay un par cosas que tengo que hacer para dar el proyecto por terminado completamente, pero ya lo puedo dar por listo y a cobrar.
Hay otras cosas que tengo pendientes, debo reunirme con un posible asociado, que significará más clientes, reponer el tiempo perdido en el blog, leer un par de libros que aún no he podido, estudiar Flex y, sobre todo, algo que me tiene emocionado y al tiempo con un dolor de cabeza permanente: Convertir los tips de POO en un curso (en principio básico) sobre el tema.
Esto último implica hacer un pensum más amplio de lo que tenía proyectado en un principio (igual cuando comencé creí que serían tres o cuatro y ya), hacer un poco más de investigación, desempolvar un par de libros (porque con los precios actuales, comprar libros es casi prohibitivo en Venezuela) y repasar algunas cosas que, aunque uses día a día, no siempre es fácil de traducir a un idioma menos técnico, que es -al final- el objetivo del curso.
Claro que tampoco es de lo único que voy a hablar, tengo cierto material recogido de mis feeds y en mis marcadores al que quiero dedicarle algunos posts y hay algunos tips que quiero revisar a ver si merece la pena que los publique, así que por escribir no faltará.
De momento este post para que sepan que ya estoy de vuelta (otra vez) y que, a pesar de las predicciones de Auyama, basadas en su fracaso con cierto curso de Ruby on Rails U_U, I Will Be a Hero!!!!