Home » Aportes »AS2 »Flash »POO »Referencia » Currently Reading:

Lo que yo sé de AS2 #Tus amigos los patrones

marzo 19, 2007 Aportes, AS2, Flash, POO, Referencia 2 Comments
Lo que yo sé de AS2 #Tus amigos los patrones

Lo que yo sé de AS2 (condensado y pasteurizado)

img*AUTOR: Juan Delgado Zárate
zarate.tv | dandolachapa.com | loqueyosede.com
FlashLa.com | After-Hours.org

Tus amigos los patrones

>Indice de contenidos

A mi me gusta pensar en los patrones como soluciones que gente muy friki y muy gafotas sabe para el problema que tienes entre las manos. Sólo son formas de organizar el código que te solucionan elegantemente un problema.

Ahora, como dijo un día Xavi Beumala (code4net.com): “si no sientes que necesitas un patrón, es que no lo necesitas”. Es decir, no se trata de que busques problemas para aplicar un patrón, sino de que apliques patrones a situaciones y problemas reales. Lo más difícil de los patrones es saber reconocer cuándo son necesarios.

NOTA IMPORTANTE: Las implementaciones de los patrones que voy a comentar a continuación son “libres”. Es decir, no me importa tanto que desde un punto de vista formal cumplan el patrón al 100% sino que guarden su “esencia” de la forma más simple posible. Si realmente estás interesado en conocer a fondo los patrones te recomiendo el libro Head First Design Patterns o si eres un tío muy gafotas, la biblia que todo talibán de los patrones lee los domingos por la mañana para desayunar: Design Patterns (by the Gang of four). Enlaces al final.

Singleton

¿Cuándo? Cuando necesitas que en una aplicación haya una y sólo una instancia de una clase.

¿Ejemplo? Un controlador de Combos. Supongamos que estamos desarrollando nuestro propio componente ComboBox, normalmente no queremos que haya 2 abiertos al mismo tiempo. Podríamos controlarlo mediante variables globales, pero ya hemos visto que eso no es muy buena idea. Singleton al rescate. La idea es tener una clase Singleton que tenga una referencia a todos los combos creados y que se encargue de coordinarlos.

Aquí va la clase que coordina, el Singleton

  1. import Combo;
  2. class ComboManager{
  3.     private static var _instance:ComboManager;
  4.     private var combos:Array;
  5.     private function ComboManager(){       
  6.          combos = new Array();
  7.     }
  8.     public static function getInstance():ComboManager{
  9.         if(_instance == null){
  10.             _instance = new ComboManager();
  11.         }
  12.         return _instance;
  13.     }
  14.     public function addCombo(combo:Combo):Void{    
  15.         combos.push(combo);
  16.     }
  17. }

Y aquí la clase combo que lo utilizaría;

  1. import ComboManager;
  2. class Combo{
  3.     public function Combo(){       
  4.         var cm:ComboManager = ComboManager.getInstance();
  5.         cm.addCombo(this);
  6.     }
  7. }

Comentarios

Es muy importante darse cuenta de que el constructor del Singleton es privado, por lo que nadie puede crear una instancia a la forma tradicional (con new). La única forma de obtener una instancia del Singleton es utilizar el método público estático getInstance. Y es dentro de getInstance donde se controla que la instancia sólo se cree una vez, el resto de veces se devuelve la ya creada.

Problemas

Como con todos los patrones, no se debe abusar del Singleton. Especialmente NO tienen que ser un un sustituto de la variables globales. En la sección de Enlaces, al final del artículo de la Wikipedia hay enlaces sobre este problema.

Factory Pattern e interfaces

Antes de comentar el Factory, vamos a explicar qué es una interface. Una clase tiene que tener todos los métodos de la interface (o interfaces) que implemente. Ejemplo:

  1. interface Application{
  2.     public function config(appXML:XML):Void;
  3.     public function start():Void;
  4. }
  1. class VideoPlayer implements Application{
  2.     public function config(appXML:XML):Void{
  3.     }
  4.     public function start():Void{
  5.     }
  6. }

Si la clase VideoPlayer no tuviera los 2 métodos de la interface, el compilador protestaría. Así que las interfaces son una forma de “obligar” a que las clases que la implementen tenga unos métodos públicos conocidos.

Lasintefaces sólo definen métodos públicos, no pueden definir ni propiedades, ni métodos privados o estáticos.

Ahora el Factory pattern.

¿Cuándo? Cuando necesitas resolver el mismo problema de distintas formas, y además hay que decidir en tiempo de ejecución cuál utilizar.

¿Ejemplo? Una aplicación para hacer un reloj que necesita 2 vistas distintas, una digital y otra analógica. Además necesitamos decidir en tiempo de ejecución cual utilizar.

Primero definimos una sencilla interface que ambas vistas van a implementar.

  1. interface iView{
  2.     public function config():Void;
  3.     public function draw():Void;
  4. }

Luego creamos las 2 vistas distintas y hacemos que implementen la interface.

  1. import iView;
  2. class AnalogView implements iView{
  3.     public function AnalogView(){}
  4.     public function config():Void{}
  5.     public function draw():Void{
  6.         // la clase analógica pinta las manillas
  7.     }
  8. }
  1. import iView;
  2. class DigitalView implements iView{
  3.     public function DigitalView(){}
  4.     public function config():Void{}
  5.     public function draw():Void{
  6.         // la clase digital pinta números
  7.     }
  8. }

Ahora creamos el modelo. Es importante fijarse en que el modelo no sabe con qué implementación de iView va a trabajar, ni siquiera importa las vistas. Es decir, no sabe si será analógico o digital. Lo único que sabe es que va a trabajar con una instancia de iView. Es ahí donde está la flexibilidad, es lo que se llama trabajar para la interface y no para implementaciones.

  1. import iView;
  2. import ViewFactory;
  3. class ClockModel{
  4.     private var view:iView;
  5.     public function  ClockModel(){
  6.         // supongamos que viene de un xml, FlashVars o algo dinámico
  7.         var viewType:String = “digital”;
  8.         // pedimos a la factoría una vista
  9.         view = ViewFactory.getView(viewType);
  10.         view.config();
  11.         view.draw();
  12.     }
  13. }

Y finalmente la factoría:

  1. import iView;
  2. import AnalogView;
  3. import DigitalView;
  4. class ViewFactory{
  5.     public static function getView(viewType:String):iView{
  6.         var v:iView;
  7.         if(viewType == “analog”){
  8.             v = new AnalogView();
  9.         } else {
  10.             v = new DigitalView();
  11.         }
  12.         return v;
  13.     }
  14. }

Vista la estructura de la factoría (un if o switch gigante), es fácil darse cuenta de que si en el futuro queremos añadir más tipos de vistas, simplemente hay que aumentar el número de casos en el if. Lo bueno es que el modelo seguirá trabajando sin problemas mientras que las nuevas vistas implementen iView.

Esto mismo se podría conseguir en lugar de con una interface haciendo que ambas vistas extiendan de una clase común. Entonces el modelo trabajaría con esa vista común en lugar de con la interface, pero el resultado y objetivo es el mismo. ¿Cuándo utilizar una interface y cuándo extender? Ver explicación en la sección de apuntes.

Comentarios

Situaciones en las que un factory es aplicable hay muchas. Todas ellas tienen es común distintas formas (implementaciones) de solucionar un mismo problema. Por ejemplo supongamos que tenemos una aplicación que necesita leer y escribir el sistema de archivos del usuario. Además queremos que la aplicación funcione on line y off line. Para conseguirlo on-line nos tendremos que basar en algún lenguaje de servidor, y para hacerlo on-line necesitaremos, Screenweaver, SWFStudio o algún otro wrapper o contenedor de swfs.

Veamos una posible interface:

  1. interface iWrapper{
  2.     // los callbacks son porque la mayoría de estas llamadas
  3.     // serán asíncronas
  4.     public function getDir(path:String,callback:Function):Void;
  5.     public function writeFile(path:String,callback:Function):Void
  6.     public function readFile(path:String,callback:Function):Void;
  7. }

La interface está definiendo qué queremos que el wrapper haga. Cómo lo haga es tarea de cada una de las implementaciones. En el caso de la implementación de servidor, seguramente sea con llamadas sendAndLoad del objeto XML, en el caso de la implementación local con Screenweaver será a través de las clases AS2 que vienen con la instalación. La parte buena es que si la aplicación trabaja con una instancia de iWrapper, cambiar la de on-line a off-line no sería problema.

Problemas

Uno de los efectos secundarios de la factoría es que TODAS las implementaciones se compilan en el swf final, aunque sólo vayamos a utilizar una. ¿Y no hay forma de evitarlo? La hay. Como el tema es un poco más avanzado, quien quiera más información sobre el tema puede seguir 2 tutoriales de la sección de Enlaces que se titulan “Crear instancias dinámicamente” y “Cargar clases dinámicamente”.

Modelo-VistaControlador

¿Cuándo? Siempre. Bueno, casi siempre. Por poco grande que sea una aplicación siempre es útil separar lógica de presentación. Y eso es la parte fundamental del MVC, separar lógica de presentación.

A pesar de que ya lo he dicho un par de veces, la implementación que pongo a continuación NO es pura, es una adaptación libre y pragmática. Prefiero repetirlo para que:

  • Nadie me salte al cuello con la implementación buena en la mano.
  • Tú, querido lector, te molestes en ir a buscar esa implementación buena y compares. En la sección de Enlaces podrás encontrar más información.

Dicho esto, comentarios sobre problemas que pueda tener mi implementación son MUY bienvenidos. Mi implementación por ejemplo, asume que sólo hay una vista. eso permite al modelo hacer llamadas directas a la vista sin necesidar de que la vista sea listener del modelo. Además tambien junto en una misma clase la vista y el controlador. Veamos el ejemplo:

Empezamos con una clase que se encarga de crear la instancia del modelo:

  1. import tv.zarate.Projects.loqueyosede.Model;
  2. class tv.zarate.Projects.loqueyosede.MVCApplication{
  3.     public static function main(m:MovieClip):Void{
  4.         var model:Model = new Model();
  5.         model.config(m);
  6.         model.start();
  7.     }
  8. }

Luego, el modelo:

  1. import tv.zarate.Projects.loqueyosede.View;
  2. class tv.zarate.Projects.loqueyosede.Model{
  3.     private var view:View;
  4.     private var timeLine_mc:MovieClip;
  5.     private var view_mc:MovieClip;
  6.     private var numberOfClicks:Number = 0;
  7.     public function Model(){}
  8.     public function config(m:MovieClip):Void{
  9.         // el modelo se guarda una referencia a la linea de tiempo principal
  10.         // basicamente para poder acceder a las FlashVars
  11.         // cuando sea necesario
  12.         timeLine_mc = m;
  13.         // creamos un mc solo para la vista
  14.         view_mc = timeLine_mc.createEmptyMovieClip("view_mc",100);
  15.     }
  16.     public function start():Void{
  17.         // creamos la instancia de la vista
  18.         view = new View();
  19.         // le pasamos la referencia al modelo y el
  20.         // clip sobre el que va a trabajar
  21.         view.config(this,view_mc);
  22.         // en este caso directamente llamamos al metodo
  23.         // start de la vista
  24.         // en aplicaciones mas complejas, el modelo
  25.         // podria primero ir a buscar datos a un servidor
  26.         // o leer un xml de configuracion
  27.         view.displayValue(numberOfClicks);
  28.     }
  29.     public function updateClick():Void{
  30.         // la vista llama a este metodo cada vez que el usuario hace click
  31.         numberOfClicks++;
  32.         // despues de actualizar
  33.         // llamamos al metodo que nos interesa de la vista
  34.         view.displayValue(numberOfClicks);
  35.     }
  36. }

Y por último la VistaControlador (abreviado, ver código adjunto para la versión completa):

  1. import tv.zarate.Projects.loqueyosede.Model;
  2. class tv.zarate.Projects.loqueyosede.View{
  3.     private var model:Model;
  4.     private var base_mc:MovieClip;
  5.     private var background_mc:MovieClip;
  6.     private var title_mc:MovieClip;
  7.     private var titleField:TextField;
  8.     private var width:Number = 0;
  9.     private var height:Number = 0;
  10.     private var OVER:String = "over";
  11.     private var OUT:String = "out";
  12.     private var PRESS:String = "press";
  13.     public function View(){}
  14.     public function config(_model:Model,_base_mc:MovieClip):Void{
  15.         // nos llega por composicion una instancia del modelo
  16.         // eso nos permitira acceder a sus metodos y propiedades publicas
  17.         model = _model;
  18.         // guardamos una referencia al clip con el que trabajara la vista
  19.         base_mc = _base_mc;
  20.         // creamos los elementos basicos
  21.         doInitialLayout();
  22.         onResize();
  23.     }
  24.     public function displayValue(value:Number):Void{
  25.         titleField.text = "Clicks > " + value;
  26.     }
  27.     private function doInitialLayout():Void{
  28.         var button_mc:MovieClip = base_mc.createEmptyMovieClip("button_mc",300);
  29.         // definimos los eventos y los delegamos al metodo manageButton
  30.         button.onPress = Delegate.create(this,manageButton,button,PRESS);      
  31.     }
  32.     private function layout():Void{}
  33.     private function onResize():Void{}
  34.     private function manageButton(mc:MovieClip,action:String):Void{
  35.         switch(action){
  36.             case(PRESS):               
  37.                 // llamamos a un metodo publico del modelo
  38.                 // que actualiza el contador de clicks
  39.                 model.updateClick();           
  40.         }      
  41.     }  
  42. }

Comentarios

Utilizo la clase MVCApplication como “punto de partida” (aunque también se podría integrar en la clase Model). Primero crea la instancia del modelo, luego lo configura mediante config, y luego llama al método start. Tanto “config” como “start” son nombres completamente arbitrarios.

Ya en el modelo, en el método start se crea la instancia de la vista, se la configura pasando una referencia al modelo y un MovieClip de trabajo.

En este momento, tanto la vista como el modelo tienen una referencia mútua, con lo que pueden fácilmente acceder a sus propiedades y métodos públicos. Es importante darse cuenta de que en esta implementación sólo puede haber una vista. ¿Y es eso importante? Pues seguro que depende de a quien le preguntes. Desde luego es menos flexible (no puede haber 2 vistas al mismo tiempo), pero yo creo que es más sencillo a la hora de ser usado.

Después de configurar la vista, es el modelo quien decide qué hacer. En este caso tan simple tampoco tiene muchas opciones, por eso llama directamente al método displayValue al que le pasa el total de clicks hechos. En aplicaciones más complejas, lo más normal es que primero tenga que hacer algo de tarea sucia como leer un xml de configuración, extraer algún parámetro de las FlashVars, instanciar otras clases relativas al modelo, etc. etc.

En la vista mostramos el número de clicks y creamos un botón para aumentarlo. Es en este momento donde se supone que debería entrar en juego el controlador. Si tuvieramos un controlador como tal, la función manageButton seguramente debería encontrarse allí. Es decir, el controlador es el encargado de decidir qué hacer con las acciones del usuario.

Aún sin el controlador hemos conseguido separar la lógica (el contado de los clicks), de la presentación (cómo la vista muestra la información). Al modelo le da exactamente igual cómo se muestre el número de clicks (si centrado en la pantalla, si en verde, rojo, grande, pequeño) y la vista tampoco le importa mucho cómo se consigue esa información. Símplemente quiere que le digan qué tiene que pintar.

[ anterior ] [ siguiente ]

img

Compártelo:

Lo que yo sé de AS2 #Tus amigos los patrones

Post relacinonados:

  1. Lo que yo sé de AS2 #Clases, instancias, propiedades
  2. Lo que yo sé de AS2 (*por Zárate)
  3. Lo que yo sé de AS2 #Comunicación entre clases
  4. Lo que yo sé de AS2 #Unos apuntes
  5. Lo que yo sé de AS2 #Introducción a AS2

YARPP
Visto 6.082 veces

Currently there are "2 comments" on this Article:

Comment on this Article:








Usuario registrado

Conectar con
Conectar con

Twitter: zguillez

AdvertisementAdvertisementAdvertisementAdvertisement

Recibe las novedades por email



Map

Ranking

Codigoactionscript.org: 4.65 sobre 5 (106 valoraciones)

twitter-widget.com