CODIGO.actionscript » POO

Programación orientada a objetos: Herencia de clases.

admin — Mon, 02 Feb 2009 00:49:59 +0000

La herencia de clases es uno de los conceptos básicos de la programación orientada a objetos. Decir que una clase hereda de otra quiere decir que esa clase obtiene los mismos métodos y propiedades de la otra clase. Permitiendo de esta forma añadir a las características heredadas las suyas propias.

Supongamos que tenemos una clase "Persona" con los métodos y propiedades básicas de una objeto persona como podrian ser "caminar" o "hablar", podríamos tener otras clases como "Guillermo" o "Elder" que comparten todas las características de una "Persona" pero que añaden características propias. Por lo que "Guillermo" y "Elder" pueden realizar las

mismas funciones que puede realizar una "Persona" y además cada una puede realizar las suyas propias, por ejemplo, "Guillermo" sabe nadar pero "Elder" no, y "Elder" sabe bailar reggeton pero "Guillermo" no.

En terminos de programación estaríamos diciendo que "Guillermo" y "Elder" son dos clases especializadas que heredan o extienden de la superclase "Persona".

Tipos de herencia de clases

Existen dos tipos de herencia:

Herencia por especialización
Herencia por generalización

En realidad la herencia es la misma, esta es una diferenciación puramente conceptual sobre la forma en que se a llegado a ella.

Una herencia por especialización es la que se realiza cuando necesitamos crear una clase nueva que disponga de las mismas características que otra pero que le añada funcionalidades. Por ejemplo si tenemos una clase que genera un botón simple, y necesitamos crear un botón que sea igual que el anterior pero que además añada un efecto al ser clicado.

La herencia por generalización es la que realizamos cuando tenemos muchas clases que comparten unas mismas funcionalidades y por homogeneizar las partes comunes se decide crear una clase que implemente toda esa parte común y se dejan solo las partes especificas en cada clase. Por ejemplo si tenemos clases para dibujar formas geométricas todas ellas

disponen de las mismas propiedades (un color de fondo, color de linea, etc..), todas estas características pueden estar en una clase general de la que hereden todas las clases concretas, evitando tener que escribir todo ese código común en todas ellas.

Herencia de clases en Actionscript

En Actionscript definimos que una clase hereda de otra con la sentencia "extends".

public class Guillermo extends Persona

Public, private o protected

Una consideración a tener en cuenta de la herencia es que una clase no hereda la propiedades o métodos privados, con lo que no tendrán acceso a ellas. Si necesitamos heredar propiedades o métodos que no queremos que sean accesibles desde fuera de las clases las definiremos como protected.

Sobreescritura de métodos

Una característica muy importante que permite la herencia es que podemos hacer que una clase implemente de manera diferente un método heredado. Haciendo que dos clases que heredan de la misma clase y heredan los mismos métodos se comporten de maneras diferentes.

Por ejemplo, unas clases de dibujo de figuras geométricas pueden heredar de una clase general la función "dibujar". Todas las clases dispondrán de esa función, pero cada clase la implementará de diferente manera y por lo tanto dibujará una figura diferente.

Para sobrescribir un método de la superclase utilizaremos la sentencia override en la definición del método.

//función de la superclase
public function traza():void
{
trace("superclase");
}

//función de la subclase
override public function traza():void
{
trace("subclase");
}

De esta manera al ejecutar la función "traza()" desde una subclase obtendremos el texto "subclase" sobrescribiendo las acciones del método de la subclase (no obtendríamos el texto "superclase").

En el caso de no querer sobrescribir por completo toda la implementación del método de la superclase, si no que lo que queremos es ampliarlo, podemos acceder a la implementación de la superclase con el operador "super".

//función de la subclase
override public function traza():void
{
super.traza();
trace("subclase");
}

En este caso, se ejecutaría la implementación del método en la superclase (obtendriamos el texto "superclase") y luego el de la subclase (obtendríamos también el texto "subclase").

Esto también lo podemos realizar en el constructor de la clase. Es bastante probable que una clase esté definiendo valores dentro de su constructor, de manera que al ser extendida nos interese que esas definiciones se continúen realizando. En este caso deberemos realizar una llamada al constructor de la superclase a través del operador "super".

package
{
public class A
{
protected var variable:uint;

public function A(n:uint)
{
variable = n;
}
}
}

package
{
import A;

public class B extends A
{
public function B(n:uint)
{
super(n); //ejecuta el contructor de la clase A, enviandole el parámetro
}
}
}

En el caso de que queramos asegurarnos de que una propiedad o método no pueda ser sobrescrita por otra clase la definiremos como final.

//función de la subclase que no permitirá ser sobreescrita
public final function traza():void
{
trace("subclase");
}

Ejemplo del uso de herencia de clases:

Veamos un sencillo ejemplo práctico: Crearemos un par de clases muy simples para dibujar un cuadrado o un círculo.

Lógicamente el primer paso es pensar que características compartirán tanto los cuadrados y los círculos.

Ambos son elementos gráficos que tienen propiedades que definen su tamaño (size), si disponen de relleno o solo de línea (fill), el color de relleno (bgColor), el grosor de linea (borderSize) y el color de la linea (borderColor).
Tambien ambás dispondrán de una función que permitirá actualizar el gráfico en caso de modificar sus propiedades.
Por último amb´s dispondran de la método que dibujará el gráfico. Lógicamente esta será la función que cada clase implementará de forma diferente.

Así que lo que haremos es crear una superclase "Grafico" que disponga de todas las propiedades mencionadas anteriormente, y dejaremos la implementación del método "dibuja()" a las subclases "Cuadrado" y "Circulo".

Empecemos escribiendo la interface de métodos públicos que deberán disponer todos los objetos que extiendan de "Grafico". En este caso serán todos los setters y getters para las propiedades, y el método para actualizar el gráfico.

package org.cristalab.graphics
{
public interface IGrafico
{
function get size():uint
function set size(n:uint):void
function get fill():Boolean
function set fill(n:Boolean):void
function get bgColor():uint
function set bgColor(n:uint):void
function get borderSize():uint
function set borderSize(n:uint):void
function get borderColor():uint
function set borderColor(n:uint):void
function update():void
}
}

Escribiremos la superclase "Grafico" que implementará la interface "IGrafico" y definirá todos los setters y getters de las propiedades.

Las propiedades las definiremos como "portected" para que sean privadas pero heredables.

El constructor de la clase recibirá todos los parámetros necesarios para definir las propiedades (les asignaremos valores por defecto por si se crea una instancia sin pasarle parámetros). Y realizará una llamada a la función "dibuja()" que es la que creará el gráfico.

package org.cristalab.graphics
{
import flash.display.Shape;
import flash.display.Sprite;
import org.cristalab.graphics.IGrafico;
//------------------------------------------------------------------------
public class Grafico extends Sprite implements IGrafico
{
protected var _size:uint;
protected var _fill:Boolean;
protected var _bgColor:uint;
protected var _borderSize:uint;
protected var _borderColor:uint;
//------------------------------------------------------------------------
public function Grafico(size:uint = 10, fill:Boolean = true, bgColor:uint = 0x000000, borderSize:uint = 0, borderColor:uint = 0x000000)
{
_size = size;
_fill = fill;
_bgColor = bgColor;
_borderSize = borderSize;
_borderColor = borderColor;
dibuja();
}
//------------------------------------------------------------------------
public function get size():uint
{
return _size;
}
public function set size(n:uint):void
{
_size = n;
}
//------------------------------------------------------------------------
public function get fill():Boolean
{
return _fill;
}
public function set fill(n:Boolean):void
{
_fill = n;
}
//------------------------------------------------------------------------
public function get bgColor():uint
{
return _size;
}
public function set bgColor(n:uint):void
{
_bgColor = n;
}
//------------------------------------------------------------------------
public function get borderSize():uint
{
return _borderSize;
}
public function set borderSize(n:uint):void
{
_borderSize = n;
}
//------------------------------------------------------------------------
public function get borderColor():uint
{
return _borderColor;
}
public function set borderColor(n:uint):void
{
_borderColor = n;
}
//------------------------------------------------------------------------
public function update():void
{
this.graphics.clear();
dibuja();
}
//------------------------------------------------------------------------
protected function dibuja():void
{
Throw.newError("clase abstracta");
}
//------------------------------------------------------------------------
}
}

Como hemos dicho, la clase "Grafico" no implementa el método "dibuja()" ya que eso depende de cada subclase, con lo que si intentamos crear una instancia de "Grafico" nos lanzará un error. Lo único que hacemos es definir que todas las subclases hereden el método y cada una lo implenete a su manera.

Escribamos ahora la clase "Cuadrado".

Esta clase extendrá de la clase "Grafico" e implementará la interface "IGrafico". Por lo tanto heredará todas las propiedades y métodos de la superclase marcados como public o protected, con lo que no necesitaremos definir las protiedades ni los setter y getters, pero dispondrá de ellos.

El constructor de esta clase recibirá como parámetros los valores del objeto a crear, y deberemos pasarselos al constructor de la superclase para que asigne los valores y ejecute la función de dibujar. Como hemos mencionado esto lo haremos utilizando la sentencia super();

Ahora solo nos quedará sobreescribir el método "dibuja()" para que se dibuje lo que nos interese en función de la clase actual, en este caso queremo sdibujar un cuadrado. Utilizaremos un override para sobrescribir el método.

package org.cristalab.graphics
{
import org.cristalab.graphics.IGrafico;
import org.cristalab.graphics.Grafico;
import flash.display.Shape;
import flash.display.Sprite;
//------------------------------------------------------------------------
public class Cuadrado extends Grafico implements IGrafico
{
//------------------------------------------------------------------------
public function Cuadrado(size:uint = 10, fill:Boolean = true, bgColor:uint = 0x000000, borderSize:uint = 0, borderColor:uint = 0x000000)
{
super(size, fill, bgColor, borderSize, borderColor);
}
//------------------------------------------------------------------------
override protected function dibuja():void
{
if (_fill == true)
{
this.graphics.beginFill(_bgColor);
}
if (_borderSize != 0)
{
this.graphics.lineStyle(_borderSize, _borderColor);
}
this.graphics.drawRect(0, 0, _size, _size);
if (_fill == true)
{
this.graphics.endFill();
}
}
//------------------------------------------------------------------------
}
}

Haremos lo mismo para la clase "Circulo". Únicamente deberemos implementar de diferente manera el método "dibuja".

package org.cristalab.graphics
{
import org.cristalab.graphics.IGrafico;
import org.cristalab.graphics.Grafico;
import flash.display.Shape;
import flash.display.Sprite;
//------------------------------------------------------------------------
public class Circulo extends Grafico implements IGrafico
{
//------------------------------------------
public function Circulo(size:uint = 10, fill:Boolean = true, bgColor:uint = 0x000000, borderSize:uint = 0, bordeColor:uint = 0x000000)
{
super(size, fill, bgColor, borderSize, borderColor);
}
//------------------------------------------------------------------------
override protected function dibuja():void
{
if (_fill == true)
{
this.graphics.beginFill(_bgColor);
}
if (_borderSize != 0)
{
this.graphics.lineStyle(_borderSize, _borderColor);
}
var radio:uint = Math.round(_size / 2);
this.graphics.drawCircle(radio, radio, radio);
if (_fill == true)
{
this.graphics.endFill();
}
}
//------------------------------------------------------------------------
}
}

A partir de aquí iremos creando tantas clases como gráficos diferentes nos interese dibujar, incluso podemos extender estas subclases en otras subclases, por ejemplo para crear objetos más complejos pero que su base sea un cuadrado o un circulo.

Comparte:

El uso correcto de Actionscript 2.0

admin — Sun, 11 Nov 2007 00:31:25 +0000

Desde que salió Flash CS y ActionScript 3.0 que han habido numerosas quejas de gente que opina que Actionscript 3 es muy diferente a Actionscript 2 y que no entiende por que Adobe ha realizado este cambio tan brusco que se está dejando fuera (según ellos) a mucha gente.

Se han oido muchas opiniones de gente que dice que continuará trabajando en Actionscript 2 por que ven muy complejo Actionscript 3. Freddie hace poco escribió un articulo sobre esta cuestión. Sobre que Actionscript 2 aún tiene mercado y que no es necesario el cambio a Actionscript 3. Es cierto que aun hay tiempo para hacer esta transición pero la pregunta es:

Â¿Realmente la transición se está haciendo de Actionscript 2 a Actionscript 3? o en realidad se está pretendiendo hacer de Actionscript 1 a Actionscript 3.

El problema es que NO se sabe programar correctamente Actionscript 2. Mucha gente cree saber programar en Actionscript 2 únicamente por utilizar MovieClipLoader o cualquier otra clase introducida para FlashPlayer 7, o simplemente por utilizar Flash 8 y seleccionar "Publicar para Actionscript 2.0" al crear la película. Pero en realidad siguen programando al estilo Actionscript_1.

Actionscript 2.0 lo introdujo Flash Mx 2004 hace más de tres años. Freddie escribió un tutorial mostrando las novedades que traía. Si nos fijamos en la última veremos que dice que Actionscript 2.0 introduce la programación orientada a objetos, y ese es el punto clave.

Flash Mx 2004 y Flash 8 permitieron combinar código de Actionscript 1 junto a código de Actionscript 2 haciendo que fuese más leve el paso de un lenguaje a otro. Permitiendo que gente que no quisiese aprender a programar orientado a objetos pudiese seguir programar como antes aprovechando las funciones que traía la versión 2. Pero esto a llevado al error de mucha gente que cree saber programar en Actionscript 2 cuando no es cierto, o por lo menos no saben hacerlo correctamente.

Hace unos días penHolder escribió un Tip y me pidió mi opinión. Le dije de debía escribirlo con programación orientada a objetos.

Antes de seguir he de decir que NO estoy criticando a penHoder ni diciendo que sea mal programador, su código es correcto y funciona perfectamente, pero es el último tip de AS2 y es un ejemplo que muestra claramente a lo que me refiero (sorry penHolder)

El ejemplo al que me refiero es este, y el código que utiliza es este:

this.createEmptyMovieClip("botonera", this.getNextHighestDepth());
var labels:Array = Array("home", "about", "services", "contact");
with (botonera) {
this._x = 50;
for (i = 1; i <= labels.length; i++) {
var modelButton:MovieClip = this.attachMovie("boton", "boton" + i, this.getNextHighestDepth());
modelButton._x = 0;
modelButton._y = ((i * 0) + this._height) + 5;
modelButton.t.text = labels[i - 1];
modelButton.onEnterFrame = function()
{
this._alpha += (this.a - this._alpha) / this.v;
if (this.hitTest(_root._xmouse, _root._ymouse, true)) {
this.a = 50;
this.v = 5;
} else {
this.a = 100;
this.v = 10;
}
};
modelButton.onMouseDown = function()
{
if (this.hitTest(_root._xmouse, _root._ymouse, true)) {
if (this._name == "boton1") {
trace("welcome home");
}
if (this._name == "boton2") {
trace("about us");
}
if (this._name == "boton3") {
trace("our services");
}
if (this._name == "boton4") {
trace("contact us");
}
}
};
}
}

Creado en Flash 8 y publicado para Actionscript 2, siendo este el resultado:

Ejemplo publicado para AS2

El ejemplo funciona perfectamente, Pero Â¿Realmente esto es un ejemplo de código creado para Actionscript 2? Hagamos una prueba:
Eliminemos del código la asignación de tipo de las variables. Osea donde pone var labels:Array dejaremos var labels y donde pone var modelButton:MovieClip dejaremos var modelButton, quedando así el código:

this.createEmptyMovieClip("botonera", this.getNextHighestDepth());
var labels = Array("home", "about", "services", "contact");
with (botonera) {
this._x = 50;
for (i = 1; i <= labels.length; i++) {
var modelButton = this.attachMovie("boton", "boton" + i, this.getNextHighestDepth());
modelButton._x = 0;
modelButton._y = ((i * 0) + this._height) + 5;
modelButton.t.text = labels[i - 1];
modelButton.onEnterFrame = function()
{
this._alpha += (this.a - this._alpha) / this.v;
if (this.hitTest(_root._xmouse, _root._ymouse, true)) {
this.a = 50;
this.v = 5;
} else {
this.a = 100;
this.v = 10;
}
};
modelButton.onMouseDown = function()
{
if (this.hitTest(_root._xmouse, _root._ymouse, true)) {
if (this._name == "boton1") {
trace("welcome home");
}
if (this._name == "boton2") {
trace("about us");
}
if (this._name == "boton3") {
trace("our services");
}
if (this._name == "boton4") {
trace("contact us");
}
}
};
}
}

En opciones de publicación seleccionemos FlashPlayer 7 y Actionscrip 1.

Comprobemos el resultado:

Ejemplo publicado para AS1

Vayamos más lejos. Eliminemos el método getNextHighestDepth() y dejemos un valor fijo, por ejemplo 1. Ahora publiquemos la pelicula para FlashPlayer 6:

Ejemplo publicado para AS1 y FlashPlayer 6 desde Flash MX

Nota: Para esta última publicación he utilizado Macromedia Flash MX. Versión de Flash que salió al mercado a principios del 2002, más de un año y medio antes de que apareciese Actionscript 2...

Cómo vemos el resultado es el mismo. Es decir, este ejemplo es 99.8% código Actionscript 1.

Entonces... Â¿Podemos considerar el código como Actionscript 2 únicamente por añadir el tipo de datos a dos Arrays? Evidentemente NO. Podremos utilizar una o varias funciones propias de Actionscript 2 pero seguiremos programando en Actionscript 1.

Cómo he dicho antes Actionscript 2 introduce la programación orientada a objetos y esa es la única manera de programar correctamente Actionscript 2.

Veamos el ejemplo escrito con programación orientada a objetos
Tampoco me voy a extender mucho en explicar este código, solo diré que utilizaremos dos objetos, uno que será la botonera que a su vez creará los objetos de los botones necesarios. Así que tendremos dos clases:
Botonera.as

class Botonera
{
private var _ruta:MovieClip;
private var _clip:MovieClip;
private var _vinculo:String;
private var _botones:Array = new Array();
private var _labels:Array = new Array();
private var _acciones:Function;
private var _x:Number;
private var _y:Number;
private var _distanciaY:Number;
public function Botonera(ruta:MovieClip, vinculo:String, labels:Array, acciones:Function, x:Number, y:Number, distanciaY:Number)
{
_x = x;
_y = y;
_distanciaY = distanciaY;
_ruta = ruta;
_vinculo = vinculo;
_labels = labels;
_acciones = acciones;
creaBotonera();
}
private function creaBotonera()
{
_clip = _ruta.createEmptyMovieClip("botonera", _ruta.getNextHighestDepth());
_clip._x = _x;
_clip._y = _y;
var total = _labels.length;
for (var i:Number = 1; i <= total; i++) {
creaBoton(_labels[i - 1],i);
}
}
private function creaBoton(label:String, id:Number):Void
{
var boton:Boton = new Boton(_clip, _vinculo, label, _acciones, _distanciaY, id);
_botones.push(boton);
}
}

Boton.as

import mx.transitions.Tween;
import mx.transitions.easing.*;
import mx.utils.Delegate;
//
class Boton
{
private var _ruta:MovieClip;
private var _clip:MovieClip;
private var _vinculo:String;
private var _label:String;
private var _accion:Function;
private var _distanciaY:Number;
private var _id:Number;

public function Boton(ruta:MovieClip, vinculo:String, label:String, accion:Function, distanciaY:Number, id:Number)
{
_ruta = ruta;
_vinculo = vinculo;
_label = label;
_accion = accion;
_distanciaY = distanciaY;
_id = id;
creaBoton();
}
private function creaBoton():Void
{
_clip = _ruta.attachMovie(_vinculo, _vinculo + _id, _ruta.getNextHighestDepth());
_clip.t.text = _label;
_clip._x = 0;
_clip._y = (_id - 1) * (_clip._height + _distanciaY);
_clip.boton = _id;
_clip.accion = _accion;
_clip.onRelease = Delegate.create(this, mouse_down);
_clip.onRollOver = Delegate.create(this, mouse_over);
_clip.onRollOut = Delegate.create(this, mouse_out);
}
private function mouse_down():Void
{
_accion(this._id);
}
private function mouse_over():Void
{
var alfa:Tween = new Tween(_clip, "_alpha", Regular.easeIn, 100, 50, 5, false);
}
private function mouse_out():Void
{
var alfa:Tween = new Tween(_clip, "_alpha", Regular.easeIn, 50, 100, 5, false);
}
}

Y en el .fla tendremos esto:

var labels:Array = new Array("home", "about", "services", "contact");
var botonera:Botonera = new Botonera(this, "Boton", labels, acciones, 50, 20, 5);

function acciones(boton)
{
if (boton == 1) {
trace("welcome home");
}
if (boton == 2) {
trace("about us");
}
if (boton == 3) {
trace("our services");
}
if (boton == 4) {
trace("contact us");
}
}

Resultado:

AS2 con POO

Evidentemente este código ahora es imposible publicarlo desde Actionscript 1, es un código orientado a objetos con lo que es un código 100% Actionscript 2.

Ahora pasemos el ejemplo a Actionscript 3
Seguiremos teniendo dos objetos, botonera y botón.

Botonera.as

package
{
import flash.display.Sprite;
import flash.utils.getDefinitionByName;
//
public class Botonera extends Sprite
{
private var _ruta:Sprite;
private var _clip:Sprite;
private var _vinculo:String;
private var _botones:Array = new Array();
private var _labels:Array = new Array();
private var _acciones:Function;
private var _x:Number;
private var _y:Number;
private var _distanciaY:Number;
public function Botonera(ruta:Sprite, vinculo:String, labels:Array, acciones:Function, x:Number, y:Number, distanciaY:Number)
{
_x = x;
_y = y;
_distanciaY = distanciaY;
_ruta = ruta;
_vinculo = vinculo;
_labels = labels;
_acciones = acciones;
creaBotonera();
}
private function creaBotonera():void
{
_clip = new Sprite();
_clip.x = _x;
_clip.y = _y;
var total:uint = _labels.length;
for (var i:uint = 1; i <= total; i++) {
creaBoton(_labels[i - 1],i);
}
addChild(_clip);
}
private function creaBoton(label:String, id:Number):void
{
var ClassReference:Class = getDefinitionByName(_vinculo) as Class;
var boton:Sprite = new ClassReference(_clip, label, _acciones, _distanciaY, id) as Sprite
_clip.addChild(boton);
}
}
}

Boton.as

package
{
import flash.display.Sprite;
import flash.text.TextField;
import flash.events.MouseEvent;
import fl.transitions.*;
import fl.transitions.easing.*;
//
public class Boton extends Sprite
{
private var _ruta:Sprite;
private var _clip:Sprite;
private var _label:String;
private var _accion:Function;
private var _distanciaY:uint;
private var _id:uint;
public function Boton(ruta:Sprite, label:String, accion:Function, distanciaY:uint, id:uint)
{
_ruta = ruta;
_label = label;
_accion = accion;
_distanciaY = distanciaY;
_id = id;
creaBoton();
}
private function creaBoton()
{
var texto = getChildByName("t");
texto.text = _label;
x = 0;
y = (_id - 1) * (height + _distanciaY);
addEventListener(MouseEvent.MOUSE_DOWN, mouse_down);
addEventListener(MouseEvent.ROLL_OVER, mouse_over);
addEventListener(MouseEvent.ROLL_OUT, mouse_out);
}
private function mouse_down(e:MouseEvent):void
{
_accion(this._id);
}
private function mouse_over(e:MouseEvent):void
{
var alfa:Tween = new Tween(this, "alpha", Regular.easeIn, 1, 0.5, 5, false);
}
private function mouse_out(e:MouseEvent):void
{
var alfa:Tween = new Tween(this, "alpha", Regular.easeIn, 0.5, 1, 5, false);
}
}
}

Y en el .fla:

var labels:Array = new Array("home", "about", "services", "contact");
var botonera:Botonera = new Botonera(this, "Boton", labels, acciones, 50, 20, 5);
addChild(botonera);

function acciones(boton)
{
if (boton == 1) {
trace("welcome home");
}
if (boton == 2) {
trace("about us");
}
if (boton == 3) {
trace("our services");
}
if (boton == 4) {
trace("contact us");
}
}

Ejemplo en Actionscript 3

Evidentemente Actionscript 3 introduce cambios respecto a Actionscript 2, elimina funciones e introduce otras. No utilizaremos attachMovie utilizaremos addChild, no utilizaremos métodos en clip, utilizaremos listeners. etc... Pero los cambios son MÃNIMOS. La base sigue siendo la misma, una programación orientada a objetos.

Conclusión:
Ãšnicamente comparen los códigos... Â¿Realmente creemos que ha cambiado tanto Actionscript_3 respecto a Actionscript 2? o es que en realidad no sabemos programar bien Actionscript_2 y aun estamos con Actionscript_1...

Comparte:

Clase de ActionScript 3 para añadir sombras a MovieClips

admin — Tue, 14 Aug 2007 15:08:07 +0000

Esta es una sencilla clase de ActionScript 3 que he escrito para añadir y modificar fácilmente sombras a MovieClips.

Lo que hago simplemente es implementar la clase DropShadowFilter para añadirle un filtro de sombra al clip.

La clase se compone básicamente de dos funciones iniSombra() y update(). En la primera añado los valores por defecto que tendrá el filtro de sombra y en la segunda es la funciónque añadirá el filtro al MovieClip con dichos parámetros. Estas dos funciones son llamadas desde el constructor de la clase.

private function iniSombra():void
{
_color = 0x000000;
_angulo = 45;
_alfa = 0.7;
_blurX = 5;
_blurY = 5;
_distancia = 5;
_strength = 0.65;
_inner = false;
_knockout = false;
_calidad = BitmapFilterQuality.HIGH;
}
private function update():void
{
_filtros = new Array();
_sombra = new DropShadowFilter(_distancia,_angulo,_color,_alfa,_blurX,_blurY,_strength,_calidad,_inner,_knockout);
_filtros.push(_sombra);
_clip.filters = _filtros;
}

Además la clase incorpora una serie de setters para modificar los parámetros del filtro. Estos setters realizan una llamada a la función update() para actualizar la sombra al cambiar cualquier parámetro.

public function set color(color:Number):void
{
_color = color;
update();
}

Esta sería la clase completa:

package
{
import flash.display.Sprite;
import flash.filters.BitmapFilter;
import flash.filters.BitmapFilterQuality;
import flash.filters.DropShadowFilter;
//------------------------------------------
public class Sombra extends Sprite
{
private var _ruta:Sprite;
private var _clip:Object;
private var _filtros:Array;
private var _sombra:BitmapFilter;
private var _color:Number;
private var _angulo:Number;
private var _alfa:Number;
private var _blurX:Number;
private var _blurY:Number;
private var _distancia:Number;
private var _strength:Number;
private var _inner:Boolean;
private var _knockout:Boolean;
private var _calidad:Number;
//------------------------------------------
public function Sombra(clip:Object)
{
_ruta = clip.parent;
_clip = clip;
iniSombra();
update();
}
//------------------------------------------
private function iniSombra():void
{
_color = 0x000000;
_angulo = 45;
_alfa = 0.7;
_blurX = 5;
_blurY = 5;
_distancia = 5;
_strength = 0.65;
_inner = false;
_knockout = false;
_calidad = BitmapFilterQuality.HIGH;
}
//------------------------------------------
private function update():void
{
_filtros = new Array();
_sombra = new DropShadowFilter(_distancia,_angulo,_color,_alfa,_blurX,_blurY,_strength,_calidad,_inner,_knockout);
_filtros.push(_sombra);
_clip.filters = _filtros;
}
//------------------------------------------
public function set color(color:Number):void
{
_color = color;
update();
}
//------------------------------------------
public function set angulo(angulo:Number):void
{
_angulo = angulo;
update();
}
//------------------------------------------
public function set alfa(alfa:Number):void
{
_alfa = alfa;
update();
}
//------------------------------------------
public function set blurX(blurX:Number):void
{
_blurX = blurX;
update();
}
//------------------------------------------
public function set blurY(blurY:Number):void
{
_blurY = blurY;
update();
}
//------------------------------------------
public function set distancia(distancia:Number):void
{
_distancia = distancia;
update();
}
//------------------------------------------
public function set strength(strength:Number):void
{
_strength = strength;
update();
}
//------------------------------------------
public function set inner(inner:Boolean):void
{
_inner = inner;
update();
}
//------------------------------------------
public function set knockout(knockout:Boolean):void
{
_knockout = knockout;
update();
}
//------------------------------------------
public function set calidad(calidad:Number):void
{
_calidad = calidad;
update();
}
//------------------------------------------
}
}

Un ejemplo de uso podría ser este (en nuestro .fla):

import Sombra;
var sombra1:Sombra = new Sombra(logo1);
var sombra2:Sombra = new Sombra(logo2);
var sombra3:Sombra = new Sombra(logo3);
sombra2.blurX = 15;
sombra2.blurY = 15;
sombra2.angulo = 90
sombra2.distancia = 20;
sombra3.alfa = 1
sombra3.color = 0x0066CC
sombra3.blurX = 15;
sombra3.blurY = 15;
sombra3.distancia = 0;

Comparte:

Articulo sobre la programación orientada a objetos en Actionscript 3

admin — Tue, 03 Jul 2007 15:05:56 +0000

Peter Elst acaba de publicar un articulo en el Adobe Developer Center sobre la programación orientada a objetos (POO) en Actionscript 3.

El artículo explica los fundamentos de la herencia, de la encapsulación y del polimorfismo, conceptos básicos para poder programar orientando a objetos.

Peter Elst es autor de libros sobre AS3 como "Object-Oriented ActionScript 3.0"

Enlace del articulo:

Object-oriented programming with ActionScript 3.0

Comparte:

Lo que yo sé de AS2 #Enlaces, enlaces, millones de enlaces

admin — Wed, 21 Mar 2007 21:51:04 +0000

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

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

Enlaces, enlaces, millones de enlaces

>Indice de contenidos

Software

Tutoriales

EventDispatcher

GDispatcher. La versión que va en el zip con el código está modificada para meterla dentro de un classpath normal y para que compile con strict en MTASC
Jorge Maestre, Comunicación basada en eventos para AS2
Cómo crear instancias de clase dinámicamente
http://www.zarate.tv/articulos/cargarclasesdinamicamente/
Using _exclude.xml, the Good, the Bad, and the Wishlist
Cómo usar _exclude con MTASC
Why does my initializer get shared across all instances like it's static?

Patrones y OOP tips

Recursos

Foros y listas de correo

Revisores

[ anterior ]

Comparte:

Lo que yo sé de AS2 #Unos apuntes

admin — Mon, 19 Mar 2007 23:09:16 +0000

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

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

Unos apuntes

>Indice de contenidos

Aquí van unos comentarios que no sé dónde encajar pero que me parecen útiles a la hora de pensar aplicaciones AS2.

Â¿Extender o interface?

Para tomar esta decisión hay varias cosas a tener en cuenta. Por ejemplo, en Flash no hay herencia múltiple (sólo se puede extender de una clase), pero se pueden implementar varias interfaces.

Sin embargo, para mi la clave viene dada por cuántas cosas en común van a hacer las distintas implementaciones. Por ejemplo es normal que un grupo de vistas tengan un montón de código común:

Tener un método setSize
Tener una instancia del modelo
Tener una variable base_mc, con una referencia al MovieClip base sobre el que trabajar.
Un método config() con parámetros comunes
...

Parece que hay bastante código común, así que se podría guardar todo ese código común en una clase CommonView y luego hacer que las vistas específicas la extiendan y sobrescriban sólo los métodos necesarios.

Sin embargo, el ejemplo puesto en el apartado del patrón Factory en el que bajo la misma interface se implementaban 2 contenedores distintos que proporcionan acceso al sistema de archivos para la misma aplicación, el código común entre la clase de Screenweaver y la clase para lenguaje de servidor es mínimo, por lo que la interface es mejor.

Â¿Extender de MovieClip? No, gracias

Ã‰ste es un tema sobre el que hay bastante "polémica" en cualquier lista de correo de Flash. Así que volveré a dejar por escrito que ésta es _mi_ forma preferida de hacerlo. Sin embargo, no es un capricho, éstas son mis razones:

En Flash no hay herencia múltiple, así que si extiendes de MovieClip no puedes extender de nada más.
Las clases que extienden de MovieClip no se instancian mediante new, sino mediante attachMovie, lo que es bastante raro desde el punto de vista de un programador.

Cuando creo clases que tienen un componente gráfico (un menú, un TextArea, un player de vídeo) mi forma de trabajar es pasar a las clases un MovieClip base sobre el que "trabajan" (utilizar composición en lugar de herencia). Algo como:

classvideoplayer{
privatevarbase_mc:MovieClip;
publicfunctionvideoplayer(_base_mc:MovieClip){
base_mc=_base_mc;
}
}

A la hora de instanciar la clase:

varvp_mc:MovieClip=timeLine_mc.createEmptyMovieClip("vp_mc",100);
varvp:videoplayer=newvideoplayer(vp_mc);

Normalmente dejo a la clase que instancia el objeto videoplayer que decida cosas como la posición x,y del MovieClip. Esto lo hago así ya que considero que la única responsabilidad del videoplayer es poner un vídeo "donde le manden", no decidir cual es la posición dentro de la pantalla, por ejemplo. Aún así, esto es una regla general que muchas veces depende de la organización de clases y objetos que tenga una aplicación en concreto.

Hasta hace poco estaba en un error que Joseba Alonso (sidedev.net) me aclaró amablemente. Las clases que heredan de MovieClip NO heredan su dinamicidad. MovieClip es una clase dinámica (se le pueden crear propiedades y métodos en tiempo de ejecución), pero las clases que extienden de ella no tienen por qué serlo.

El problema (ventaja al mismo tiempo en algunas ocasiones) de las clases dinámicas es que se le pueden crear propiedades y métodos en tiempo de ejecución. El problema de eso es que si te equivocas escribiendo el nombre de una propiedad, el compilador no lanza error ya que sobreentiende que estás creando una propiedad nueva. Ejemplo:

dynamicclassmiClaseDinamica{
publicvarvariable:String="Helloworld";
publicfunctionmiClaseDinamica(){}
}

A la hora de usarla:

varinstancia:miClaseDinamica=newmiClaseDinamica();
varvalor:String=instancia.avriable;//elcompiladorNOdaerror

A pesar del error (usar "avriable" en lugar de "variable"), el compilador asume que se está accediendo a una variable que se ha creado en tiempo de ejecución, cuando lo más normal es que queramos acceder a la propiedad "variable".

Pero esto al mismo tiempo es una ventaja. Â¿Cuántas veces habremos creado propiedades a un MovieClip en tiempo de ejecución? Algo como:

for(varx:Number=0;x<10;x++){
varboton:MovieClip=timeLine_mc.createEmptyMovieClip("boton_"+x,100+x);
boton.opcion=x;
}

Aunque útil, muchas veces es mejor crear una pequeña clase para el manejo del botón. Esa clase podría tener una propiedad pública "opcion" sobre la que estableceríamos el valor.

Objetos responsables

Uno de los principios OOP es que cada objeto haga única y exclusivamente lo que tiene que hacer. Cuando una clase sabe demasiado o hace demasiado, se le conoce como la clase Dios o God Object (ver enlace al final).

Sin llegar a límites absurdos, casi siempre es mejor trabajar con muchas clases pequeñas, cortas y concisas que con clases de 1.000 líneas. Que cada una haga su pequeño trabajito y poco más. Esto claramente favorece la reutilización y la depuración de errores (el código a revisar por clase es menor).

Supongamos que tenemos una clase para pintar un player de vídeo. Aquí van 2 ejemplos de implementación:

importVideoPlayer;
classA{
publicfunctionA(){
varvp:VideoPlayer=newVideoPlayer(timeLine_mc);
}
}

classVideoPlayer{
privatevarbase_mc:MovieClip;
publicfunctionVideoPlayer(timeLine_mc:MovieClip){
base_mc=timeLine_mc.createEmptyMovieClip("base_mc",100);
base_mc._x=10;
base_mc._y=10;
//ahoraempezaríamosapintarelpropioplayer
}
}

En el código anterior, la clase VideoPlayer se está encargando de crearse su propio clip sobre el que trabajar y de colocarlo en la posición deseada. Sin embargo la siguiente implementación es más flexible:

importVideoPlayer;
classA{
publicfunctionA(){
video_mc=timeLine_mc.createEmptyMovieClip("video_mc",100);
video_mc._x=10;
video_mc._y=10;
varvp:VideoPlayer=newVideoPlayer(video_mc);
}
}

classVideoPlayer{
privatevarbase_mc:MovieClip;
publicfunctionVideoPlayer(_base_mc:MovieClip){
base_mc=_base_mc;
//ahoraempezaríamosapintarelplayer
}
}

En la segunda versión la clase VideoPlayer no tiene la responsabilidad de crear su MovieClip de trabajo ni de colocarlo en la pantalla. Â¿Por qué debería hacerlo si no lo necesita? Que sea la clase que lo instancia quien tenga esa responsabilidad. Así cuando haya que reutilizar la clase de VideoPlayer, no hay que hacerle ninguna modificación.

Dicho esto, el astuto lector estará pensando que la clase VideoPlayer podría recibir como parámetros la posición x,y donde se tiene que pintar, el nombre del MovieClip y la profundidad a la que va.... sí, técnicamente es posible, pero para qué pasar un montón de parámetros cuando se puede no pasar ninguno : )

Mejor que no te acoples

Una de las normas consideradas como correctas dentro de la programación orientada a objetos es que las clases entre sí deben estar poco "acopladas". Eso significa que cuanto menos sepa una clase de otra, mejor. Siempre que sea posible es más flexible que las clases trabajen sobre parámetros en lugar de hacerlo sobre otros objetos. Ejemplo:

importB;
classA{
publicvarvariable:String="Helloworld",
publicfunctionA()
{
vara:A=newA(this);
}
}

importA;
classB{
public function B(a:A){
trace(a.variable)
}
}

Según la estructura de código de arriba, la clase B necesita importar la clase A para acceder a su propiedad pública cuando realmente no es necesario. Modificando el código como sigue, las clases no están acopladas:

importB;
classA{
privatevarvariable:String="Helloworld",
publicfunctionA(){
vara:A=newA(variable);
}
}

classB{
publicfunctionB(toTrace:String){
trace(toTrace);
}
}

El resultado es el mismo, pero en el segundo caso la clase B no necesita a la clase A para nada. Si por necesidades del proyecto necesitamos que sea la clase C en lugar de la A la que inicie el proceso, a la clase B le va a dar igual porque lo único que necesita es una cadena en el constructor.

Como toda regla general, depende mucho del proyecto decidir si pasar una instancia de una clase o un montón de parámetros.

Protos Nunca Mais

Una de las preguntas más habituales para la gente que está dando el paso de AS1 a AS2 es cómo reaprovechar protos hechos en AS1 en AS2. Para mi la salida más natural a los protos son clases con un método estático para cada proto.

Ejemplo de proto sacado de Layer51

String.prototype.PALINDROME=function(){
returnthis+this.split("").reverse().join("");
};

classtv.zarate.Utils.StringUtils{
publicstaticmethodpalindrome(s:String):String{
returns+s.split("").reverse().join("");
}
}

A partir de ese momento, las llamadas serían así:

importtv.zarate.Utils.StringUtils;
trace(StringUtils.palindrome("wadus"));

Es importante fijarse en que para utilizar el método estático no hace falta crear una instancia de la clase StringUtils;

Como en los métodos estáticos no se puede hacer la referencia a "this" que se hacía en el proto, se pasa como parámetro el objeto (en este caso una cadena) con el que el método tiene que "trabajar". Por supuesto si hubiera que trabajar con más parámetros, se pasarían a continuación.

Â¿Cuándo se compila una clase?

Algo que no está meridianamente claro es cuándo el compilador incluye una clase en un swf. La respuesta es cuando esa clase está referenciada *en el código*. Y resalto lo de "en el código" porque si la clase está importada pero no usada, no se compila. Ejemplo:

importclassB;
classA{
publicfunctionA(){}
//laclaseBnosecompila
}

importclassB;
class A{
public function A(){
var b:B = new B();
}
//laclaseBsecompila
}

importclassB;
classA{
privatevarb:B;//AQUITAMBIENSECOMPILA!
publicfunctionA(){
}
}

Otra de las ventajas de utilizar MTASC es que por defecto avisa con un warning cuando se están importando clases que luego no son utilizadas dentro del código.

Â¿Y se puede evitar que una clase se compile incluso cuando se ha referenciado en el código? Claro que sí, aunque la forma de hacerlo no sea muy "amigable". Se trata de utilizar archivos *_exclude.xml, pero como el tema es un poco largo, en la sección de Enlaces dejo recursos sobre el tema.

Importando packages

Algo muy habitual es importar un package completo utilizando "*":

importcom.xfactorstudio.xml.xpath.*;

Â¡OJO! El compilador NO incluye todas las clases del package, ya que hace su trabajo de optimización y sólo compila las que están referenciadas en el código.

Â¿Entonces por qué no se importa siempre todo el package? Yo diría que es una cuestión didáctica. Prefiero importar explícitamente sólo las clases que voy a utilizar y así poder ver rápidamente de un vistazo las relaciones entre clases.

Getters y setters implícitos y explícitos

Se conocen por getters/setters a los métodos que permiten establecer y recuperar el valor de una variable. La idea es que la variable en si sea privada, y que para que acceder a ella haya que llamar a estos métodos. Â¿Y por qué querría nadie obligar a usar un método para saber el valor de una variable? Pues porque hay veces que al cambiar el valor de una variable, otras variables
relacionadas también cambian su valor. Por ejemplo:

classA{
privatevarprice:Number;
publicfunctionA(){
}
publicfunctiongetPrice():Number{
returnprice;
}
publicfunctionsetPrice(p:Number):Void{
price=p;
updateBasketPrice();//acciónrelacionada
}
}

Estos son los getters/setters explícitos. Y son explícitos porque para saber el valor de la variable desde fuera de la clase, hay que llamar a un método.

Pero Flash permite hacerlos de forma implícita. Lo siguiente es perfectamente válido:

classA{
privatevar_price:Number;
publicfunctionA(){}
publicfunctiongetprice():Number{
return_price;
}
publicfunctionsetprice(p:Number):Void{
_price=p;
updateBasketPrice();//accionrelacionada
}
}

Â¿Ventajas de un método sobre otro? Técnicamente yo diría que no hay, pero hay programadores que prefieren hacer saber que se accede a un método. Otros dicen que no tiene por qué dar explicaciones. A gusto del consumidor.

Claro, que también hay gente que piensa directamente que los getters y setters deberían desaparecer de la faz de la tierra. En la sección de Enlaces hay más sobre ello para quien le interese.

Strong data typing

Strong data typing es de esos términos que casi mejor no traducir. Pero vamos, significa que le asignes un tipo a todas las propiedades, parámetros y tipos devueltos por los métodos. Aunque no es obligatorio, yo creo que es muy recomendable hacerlo.

varmyString:String="";
varmyNumber:Number=0;
publicfunctionwadus():Void{
}
//utiliza Void si tu método no devuelve nada

Hay una no muy buena costumbre a la hora de definir el tipo de las propiedades de las clases. Por ejemplo:

classA{
public var myNumber:Number = 5; // bien
public var myArray:Array = new Array(); // MAL!
public var mySecondArray:Array;
public function A(){
// aquí o en cualquier otro método, bien
mySecondArray = new Array();
}
}

Cuando se definen las variables de una clase sólo se puede definir el valor por defecto para las variables de tipos primitivos: String, Boolean y Number. Nada que tenga que ver con un new. El player de Flash no maneja muy esas definiciones (buscar en la sección de Enlaces "Why does my initializer get shared across all instances like it's static?").

[ anterior ] [ siguiente ]

Comparte:

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

admin — Sun, 18 Mar 2007 23:37:55 +0000

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

*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

import Combo;
class ComboManager{
private static var _instance:ComboManager;
private var combos:Array;
private function ComboManager(){
combos = new Array();
}
public static function getInstance():ComboManager{
if(_instance == null){
_instance = new ComboManager();
}
return _instance;
}
public function addCombo(combo:Combo):Void{
combos.push(combo);
}
}

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

import ComboManager;
class Combo{
public function Combo(){
var cm:ComboManager = ComboManager.getInstance();
cm.addCombo(this);
}
}

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:

interface Application{
public function config(appXML:XML):Void;
public function start():Void;
}

class VideoPlayer implements Application{
public function config(appXML:XML):Void{
}
public function start():Void{
}
}

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.

interface iView{
public function config():Void;
public function draw():Void;
}

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

import iView;
class AnalogView implements iView{
public function AnalogView(){}
public function config():Void{}
public function draw():Void{
// la clase analógica pinta las manillas
}
}

import iView;
class DigitalView implements iView{
public function DigitalView(){}
public function config():Void{}
public function draw():Void{
// la clase digital pinta números
}
}

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.

import iView;
import ViewFactory;
class ClockModel{
private var view:iView;
public function ClockModel(){
// supongamos que viene de un xml, FlashVars o algo dinámico
var viewType:String = â€œdigitalâ€;
// pedimos a la factoría una vista
view = ViewFactory.getView(viewType);
view.config();
view.draw();
}
}

Y finalmente la factoría:

import iView;
import AnalogView;
import DigitalView;
class ViewFactory{
public static function getView(viewType:String):iView{
var v:iView;
if(viewType == â€œanalogâ€){
v = new AnalogView();
} else {
v = new DigitalView();
}
return v;
}
}

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:

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

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:

import tv.zarate.Projects.loqueyosede.Model;
class tv.zarate.Projects.loqueyosede.MVCApplication{
public static function main(m:MovieClip):Void{
var model:Model = new Model();
model.config(m);
model.start();
}
}

Luego, el modelo:

import tv.zarate.Projects.loqueyosede.View;
class tv.zarate.Projects.loqueyosede.Model{
private var view:View;
private var timeLine_mc:MovieClip;
private var view_mc:MovieClip;
private var numberOfClicks:Number = 0;
public function Model(){}
public function config(m:MovieClip):Void{
// el modelo se guarda una referencia a la linea de tiempo principal
// basicamente para poder acceder a las FlashVars
// cuando sea necesario
timeLine_mc = m;
// creamos un mc solo para la vista
view_mc = timeLine_mc.createEmptyMovieClip("view_mc",100);
}
public function start():Void{
// creamos la instancia de la vista
view = new View();
// le pasamos la referencia al modelo y el
// clip sobre el que va a trabajar
view.config(this,view_mc);
// en este caso directamente llamamos al metodo
// start de la vista
// en aplicaciones mas complejas, el modelo
// podria primero ir a buscar datos a un servidor
// o leer un xml de configuracion
view.displayValue(numberOfClicks);
}
public function updateClick():Void{
// la vista llama a este metodo cada vez que el usuario hace click
numberOfClicks++;
// despues de actualizar
// llamamos al metodo que nos interesa de la vista
view.displayValue(numberOfClicks);
}
}

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

import tv.zarate.Projects.loqueyosede.Model;
class tv.zarate.Projects.loqueyosede.View{
private var model:Model;
private var base_mc:MovieClip;
private var background_mc:MovieClip;
private var title_mc:MovieClip;
private var titleField:TextField;
private var width:Number = 0;
private var height:Number = 0;
private var OVER:String = "over";
private var OUT:String = "out";
private var PRESS:String = "press";
public function View(){}
public function config(_model:Model,_base_mc:MovieClip):Void{
// nos llega por composicion una instancia del modelo
// eso nos permitira acceder a sus metodos y propiedades publicas
model = _model;
// guardamos una referencia al clip con el que trabajara la vista
base_mc = _base_mc;
// creamos los elementos basicos
doInitialLayout();
onResize();
}
public function displayValue(value:Number):Void{
titleField.text = "Clicks> " + value;
}
private function doInitialLayout():Void{
var button_mc:MovieClip = base_mc.createEmptyMovieClip("button_mc",300);
// definimos los eventos y los delegamos al metodo manageButton
button.onPress = Delegate.create(this,manageButton,button,PRESS);
}
private function layout():Void{}
private function onResize():Void{}
private function manageButton(mc:MovieClip,action:String):Void{
switch(action){
case(PRESS):
// llamamos a un metodo publico del modelo
// que actualiza el contador de clicks
model.updateClick();
}
}
}

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 ]

Comparte:

Lo que yo sé de AS2 #Comunicación entre clases

admin — Sat, 17 Mar 2007 23:20:18 +0000

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

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

Comunicación entre clases

>Indice de contenidos

Una de las partes más importantes y que más confusión y problemas ha generado de AS2 es la comunicación entre clases. Foros y listas de correo están llenos de problemas y dudas sobre "ámbitos", "eventdispatchers" y "delegates".

Como regla general yo diría:

Si necesitas comunicación dentro de la misma clase, siempre Delegate.
Si necesitas que más de una clase escuche lo que hace otra, siempre EventDispatcher.
Si la comunicación es 1:1, depende.

Vamos a ver el funcionamiento de los 2 métodos.

Delegate

NOTA: Lo que voy a contar aquí es prácticamente un copy&paste de un tuto que publiqué hace tiempo y que está enlazado al final. Si lo leíste en su día, te puedes saltar lo que sigue sin problemas.

Los foros de Flash están llenos de preguntas que tienen que ver con el "scope" o ámbito dentro de los famosos "callbacks" de objetos como XML, LoadVars, XMLSocket, etc. Flash necesita estas funciones porque las llamadas al servidor en Flash son asíncronas, es decir, el player no detiene la ejecución del código cuando se hace, por ejemplo, una petición de un fichero xml:

classA{
private var oneVar:String="Helloworld";
functionA(){
varmyXML:XML = newXML();
myXML.ignoreWhite = true;
myXML.onLoad=function():Void{
trace(oneVar); //undefined Â¬Â¬
}
myXML.load("myXML.xml");
}
}

Esto pasa porque el ámbito "dentro" del onLoad es el propio objeto myXML, NO la clase. Puedes hacer la prueba haciendo trace(this) dentro del onLoad. Una de las primeras soluciones que se utilizó para esto fue crear dentro de la función principal una

variable que hacía referencia a la propia clase. Algo como esto:

classA{
private var oneVar:String="Helloworld";
functionA(){
var owner=this;
var myXML:XML = newXML();
myXML.ignoreWhite = true;
myXML.onLoad = function():Void{
trace(owner.oneVar); //yeah!
}
myXML.load("myXML.xml");
}
}

Y esto funciona. Este comportamiento "peculiar" de Flash (de los ECMAScript, vamos) se llama closure.

ámbito en las llamadas asíncronas. Pues a todo esto llegó la versión 7.2 del Flash IDE y el señor Mike Chambers introdujo la clase Delegate. Utilizando esa clase dejaríamos el código anterior en algo como esto:

importmx.utils.Delegate;
classA{
private var oneVar:String = "Hello world 2";
function A(){
var myXML:XML = new XML();
myXML.ignoreWhite = true;
myXML.onLoad = Delegate.create(this,xmlLoaded);
myXML.load("myXML.xml");
}
private function xmlLoaded(success:Boolean):Void{
trace(oneVar);
}
}

Estamos "delegando" el onLoad en la función xmlLoaded, pero, lo más importante, el ámbito de la función xmlLoaded es la clase original, por lo que "encontramos" la variable sin problemas.

Esto definitivamente NO es lo mismo que hacer: myXML.onLoad = xmlLoaded. Si lo probáis, estaréis con el mismo problema que antes, el ámbito de la función xmlLoaded será el objeto myXML, por lo que el trace volverá a ser undefined.

El mayor problema de la clase de Macromedia (aún era Macromedia) es que NO permite el paso de parámetros a la función delegada, pero pronto llegaron los frikis para solucionarlo haciendo sus propias clases para delegar. La que yo utilizo es una copia con alguna modificación de una que encontré en la lista de MTASC. Con estas nuevas clases se pueden pasar parámetros de la siguiente forma:

myXML.onLoad=Delegate.create(this,xmlLoaded,"val1",val2);

OJO, nuestros parámetros llegarán después de los "oficiales", en este caso el típico success que llega a los onLoad del objeto XML.

EvenDispatcher

La misión básica de EvenDispatcher es permitir que varios objetos estén "escuchando" los eventos que lanza otro. EvenDispatcher siempre trata de comunicación entre clases, ya sea 1:1 (un emisor y un receptor) o 1:n (un emisor y varios receptores).

Técnicamente es una implementación del patrón Observer (ver enlaces al final) y fue introducida en su día por Macromedia. Pero como casi siempre apareció una versión libre, GDispatcher, en esta ocasión a cargo de Grant Skinner (gskinner.com).

Las clases que emiten eventos con EvenDispatcher son completamente independientes de quien esté escuchando, nunca saben si los escuchan 1 o 10, ellos sólo se limitan a emitir. Son como una radio o televisión con audiencia.

Sólo el objeto emisor necesita importar GDispatcher. Algo como lo siguiente:

importcom.gskinner.GDispatcher;
classbroadcaster{
public var addEventListener:Function;
public var removeEventListener:Function;
private var dispatchEvent:Function;
public function broadcaster(){
GDispatcher.initialize(this);
send();
}
private function send():Void{
var ev:Object = new Object();
ev.type = "myEvent";
ev.variable = "wadus";
dispatchEvent(ev);
}
}

import broadcaster;
class receiver{
public function receiver(){
varbr:broadcaster = newbroadcaster();
br.addEventListener("myEvent",this,"callback");
}
private function callback(ev:Object):Void{
trace(ev.type+""+
ev.variable);
}
}

Lo primero que llama la atención es que hayamos definido en la clase emisora unas variables del tipo Function. Si alguien se molesta en abrir GDispatcher puede ver que lo que hace en el método initialize es crear en tiempo de ejecución funciones a la clase que se le pasa como parámetro. Así que tenemos que definir esas mismas funciones como propiedades de nuestra clase para que el compilador no se queje de que el método al que el receptor trata de acceder (addEventListener) no existe.

La clase receptora es bastante simple. Simplemente importa a la emisora y se añade como listener para un evento concreto. Para hacerlo utiliza el método addEventListener pasando como parámetros el evento que quiere escuchar, el objeto que está escuchando (la propia clase (this) en este caso, pero se puede hacer que escuche otra) y la función que va a recibir la llamada. OJO que la función está pasada como cadena.

La implementación que hemos visto es perfectamente válida y funcional pero se puede mejorar. El primer problema es que el literal del nombre del evento ("myEvent") lo estamos repitiendo dos veces, una en el emisor y otra en el receptor. Malo. Otra es que el tipo del parámetro que llega a la función receptora es del tipo genérico Object, lo que no nos permite ninguna validación de tipos al compilar. Malo también. Bueno, pues las 2 cosas las vamos a solucionar en la misma jugada. Vamos a crear un objeto específico para el evento y será ese objeto "conocido" el que se envíe.

classmyEvent{
public static var EVENT_LITERAL:String = "eventOne";
public var type:String = "";
public var variable:Number;
public function myEvent(_variable:Number){
type = EVENT_LITERAL;
variable = _variable;
}
}

importcom.gskinner.GDispatcher;
import myEvent;
class broadcaster{
public var addEventListener:Function;
public var removeEventListener:Function;
private var dispatchEvent:Function;
public function broadcaster(){
GDispatcher.initialize(this);
send();
}
private function send():Void{
var ev:myEvent = new myEvent(5);
dispatchEvent(ev);
}
}

import broadcaster;
import myEvent;
class receiver{
public function receiver(){
var br:broadcaster = new broadcaster();
br.addEventListener(preventivamente_LITERAL,this, "callback");
}
private function callback(ev:myEvent):Void{
trace(ev.type + " "
+ ev.variable);
}
}

Mucho mejor. El literal con el nombre del evento sólo se define una vez en la clase myEvent. Se define como variable estática para que la clase receptora pueda utilizarlo sin tener que crear una instancia. La propiedad type se define para ser compatibles con EventDispatcher y GDispatcher.

Además con la nueva implementación el tipo del evento que llega al receptor es myEvent y no Object, por lo que tendremos validación de tipos al compilar.

Si sustituyes myEvent, por videoStarted, applicationReady, menuButtonPressed y similares, es cuando se empieza a ver la utilidad de EvenDispatcher (vamos, de un patrón Observer).

EvenDispatcher Â¿vs? Delegate

Una vez vistos EventDispatcher y Delegate, Â¿hay situaciones en las que se pueda elegir entre usar una opción o la otra? Ya hemos visto que la comunicación dentro de la misma clase siempre es con Delegate, así la decisión viene cuando hay que comunicar 2 clases. Vamos a ver cómo.

importBroadcaster;
importtv.zarate.utils.Delegate;
class Receiver{
public function Receiver(){
var buttonCallback:Function = Delegate.create(this, buttonPressed);
var broadcaster:Broadcaster = newBroadcaster(buttonCallback);
}
private function buttonPressed():Void{
//este método se ejecuta cuando se presione el botón
//en la clase emisora
}
}

class Broadcaster{
public function Broadcaster(buttonPressedCallback:Function){
var button:MovieClip = base_mc.createEmptyMovieClip("button", 100);
button.onPress = buttonPressedCallback;
}
}

Atención a la jugada. La clase receptora crea una función delegada y la pasa como parámetro a la emisora que simplemente se lo asigna al evento onPress de su botón. Así que cuando el botón es presionado, la clase emisora recibe sin problemas el evento.

Ahora, Â¿qué hacemos si hay que pasar parámetros en la llamada? Esto es algo que NO podríamos hacer:

button.onPress = buttonPressedCallback("parametro");

Ya que al añadir "()" estaríamos ejecutando la función. Si necesitamos pasar parámetros con este método, habría que pasar por una función intermedia. Repito sólo la clase emisora:

importtv.zarate.utils.Delegate;
class Broadcaster{
public function Broadcaster(externalCallback:Function){
var button:MovieClip = base_mc.createEmptyMovieClip("button", 100);
button.onPress = Delegate.create(this, butPressed, externalCallback);
}
private function butPressed(externalCallback:Function):Void{
externalCallback("parametro");
}
}

Al utilizar la clase emisora internamente una función para recibir el evento onPress del botón, ya puede pasar los parámetros que quiera al callback externo.

[ anterior ] [ siguiente ]

Comparte:

Lo que yo sé de AS2 #Clases, instancias, propiedades

admin — Sat, 17 Mar 2007 11:34:54 +0000

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

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

Clases, instancias, propiedades

>Indice de contenidos

Cualquier elemento de una película Flash puede ser una clase. Un botón, un menú, un componente ScrollArea... lo que sea. Pero no sólo los elementos gráficos pueden ser clases. La "lógica" de tu aplicación también lo puede ser: cuando hago click aquí, sumo 2 y muevo el menú. También puedes crear clases para mandar y recibir datos del servidor, etc.

Decidir qué convertimos en clase y qué dejamos como código "normal" es algo que siempre depende del programador y del proyecto. Supón que quieres hacer una aplicación que lee datos de un xml, los muestra en un campo de texto y que tiene un botón para mandar el texto de nuevo al servidor. El conjunto de clases podría variar desde una clase para hacerlo todo, a una clase para la aplicación, otra para la lectura y envio de datos, otra para el campo de texto y otra para el botón.

Meter todo en la misma clase no parece una idea muy feliz. Podrías fácilmente llegar a 1.000 líneas de código y estarías mezclando lógica con presentación, no podrías reusar nada de lo que hayas hecho... Por el contrario hacer una clase para todos y cada uno de los elementos de una aplicación te puede llevar a una pesadilla de montones de clases que no hacen prácticamente nada. Como siempre, es cuestión de práctica. Asume que para mejorar te tienes que equivocar, así que cuanto más practiques menos errores cometerás.

Como regla general yo diría que siempre es bueno conjuntos de clases para:

Manter el estado y la lógica de la aplicación. Lo que luego llamaremos modelo.
Una o varias clases para el pintado. Lo que luego llamaremos vista.
Una o varias clases para el acceso y escritura de los datos. Suponiendo una aplicación que maneja usuarios (alta, baja, edición), en lugar de poner todos esos procesos (lectura de xml, envio de nuevos datos al servidor) en el modelo, yo prefiero que el modelo haga esas peticiones a una clase específica. De esa forma el modelo (y la aplicación) es independiente de dónde vienen los datos.
Clases para componentes gráficos. Típico TextArea, RadioButton, CheckBox, etc. etc.
Tener clases comunes para tareas no específicas de un proyecto. Es muy común que necesitemos una clase para pintar un cuadrado o un círculo. En ese caso se puede crear una clase llamada rawUtils con métodos estáticos para círculo, cuadrado, triángulo... Lo mismo para sustituir los protos y añadir funcionalidades extra a String o Array.

Partes de una clase

Cuando se crea una clase, hay que utilizar su classpath completo mas su nombre para definirla. Por ejemplo:

classtv.zarate.Utils.Trace{
//codigo
}

El nombre de la clase es "Trace" (y ese tiene que ser el nombre del archivo .as), y se encuentra dentro de las carpetas tv > zarate > Utils. A la hora de importarla también hay que utilizar toda la definción de la clase:

importtv.zarate.Utils.Trace;

Dentro de una clase tenemos propiedades (que contienen los datos o información de una clase) y métodos (normalmente para realizar operaciones con la información de las propiedades).

Todos los métodos de una clase pueden acceder a sus propiedades, pero además puede definir variables locales. Las variables locales a una función se eliminan cuando la ejecución de una función se termina.

En AS2 todo lo que tiene representación gráfica se hace sobre objetos MovieClips. Es decir, no se puede "pintar" sobre nada que no sea un MovieClip. Esto NO quiere decir que tus clases tengan que extender de MovieClip, pero de eso hablaremos luego.

Diferencias entre clases/métodos estáticos e instancias de clases

Una clase "normal" es aquella de la que se crean instancias utilizando la palabra clave "new". Algo como lo siguiente:

varinstance:MyClass=newMyClass();

classMyClass{
publicvarvariableAccesible:String="Aquí puede acceder todo el mundo";
privatevarvariableNoAccesible:String="Aquí, teóricamente, no";
publicfunctionMyClass(){
//estemétodoeselconstructor
//yseejecutasiemprequesecrea
//unanuevainstancia
}
}

Las clases estáticas son aquellas que se pueden utilizar sin crear una instancia. Por ejemplo la clase Math:

varpi:Number=Math.PI;

Â¡OJO! Las clases normales pueden tener variables estáticas. De hecho, son muy útiles para algunos casos. Por ejemplo. Supongamos que tenemos una clase que representa un juego.

classMyGame{
publicstaticvarRIGHT:String="right";
publicstaticvarWRONG:String="wrong";
privatevarstate:String="";
}

Eso nos permite hacer algo como:

vargame:MyGame=newMyGame();
game.state=MyGame.RIGHT;

De esa forma sólo definimos la cadena "right" en un sitio y a partir de ahí utilizaríamos el valor de la variable estática. De esa forma nos ahorraremos errores tipográficos y, si por ejemplo hubiera que cambiar la cadena "right" por "correcto", no habría ningún problema ya que estaríamos accediendo a una variable.

Público vs privado

Los métodos y las propiedades de una clase pueden ser públicos o privados. Aunque sea bastante obvio, las propiedades y métodos públicos son accesibles por la propia clase y clases externas. Todo lo que sea privado sólo puede ser usado (en teoría) por la propia clase y las que extiendan de ella. Por ejemplo:

classA{
publicfunctionA(){
}
publicfunctiondoSomethingPublic():Void{
}
privatefunctiondoSomethingPrivate():Void{
}
}

importclassA;
vara:A = newA():
a.doSomethingPublic(); //bien
a.doSomethingPrivate(); //ERRORalcompilar

Las propiedades y métodos públicos componen la API (Application Programming Interface) de nuestra clase para otras clases. Es decir, suponen el conjunto de "cosas" que se pueden hacer con ella.

Como regla general, haz privado todo lo que puedas. Si no hay una buena razón para que un método sea público, mejor que sea privado. La razón es sencilla. Supongamos que pasado un tiempo nos damos cuenta de que hay que pasar un método de privado a público. Como ninguna clase externa

puede estar utilizando ese método (es privado), no romperemos la compatibilidad hacia atrás, no habrá problemas al compilar.

Sin embargo el caso contrario no es tan sencillo. Si pasamos un método (o propiedad) de público a privado, nos podemos encontrar con que otras clases externas lo pueden estar utilizando. Al intentar recompilar, podríamos tener errores.

Recordar también que en AS2 si no se define public/private, tanto las propiedades como los métodos son públicos por defecto.

Acceder a los métodos y propiedades de una clase desde la propia clase

Para acceder a las propiedades y métodos de una clase desde la propia clase NO es necesario utilizar this. Dicho esto, hay gente que lo considera best practice ya que ayuda a ver dentro de un método si se está usando una propiedad de la clase, una variable local, o un parámetro.

Composición y herencia

Herencia

Una clase hereda de otra utilizando la palabra clave extends. Y cuando una clase hereda de otra automáticamente añade a su código el código de la clase padre, todos sus métodos y propiedades.
Lo bueno es que la clase hija puede decidir si quiere modificar el comportamiento de la clase padre o simplemente añadirle nuevas funcionalidades. Ejemplo:

classA{
publicvargreeting:String="helloworld";
publicfunctionA(){
}
publicfunctionmyFirstTrace():Void{
trace(greeting+"IÂ´mclassA!");
}
publicfunctionmySecondTrace():Void{
trace("ClassAsecondtrace");
}
}

importA;
classBextendsA{
public function B(){
super();
greeting = "Hello people";
}
public function myFirstTrace():Void{
super.myTrace();
trace(greeting + " IÂ´m class B!");
}
public function mySecondTrace():Void{
trace("ClassBsecondtrace");
}
}

Fijaos como la clase B no necesita definir como propiedad "greeting", ya que la hereda de A. Luego, si llamamos al método myFirstTrace de la clase B tendremos 2 traces, el de A y el de B. Esto
es así porque la clase B está llamando al método de la clase padre con la palabra clave super. Importante notar que la traza que obtendremos de la clase A no es la esperada, ya que la variable
"greeting" ha sido predefinida en la clase B.

Sin embargo, si llamamos al método mySecondTrace de la clase B sólo obtendremos una traza, ya que la clase B no llama al método de la clase padre.

Predefinir completamente los métodos o propiedades de la clase padre o llamarlos mediante super y luego ejecutar más acciones específicas depende por completo de la situación y de lo que queramos
conseguir.

Composición

Utilizamos composición entre 2 clases cuando una clase recibe como parámetro una instancia de la otra. Por ejemplo:

classA{
publicfunctionA(){}
}

importA;
class B{
private var a:A;
public function B(_a:A){
a = _a;
}
}

importA;
importB;
classC{
publicfunctionC(){
vara:A=newA();
varb:B=newB(a);//BrecibecomoparámetrounainstanciadeA
}
}

Que empiece la fiesta

Después de probar varios métodos creo que la forma más sencilla de iniciar una aplicación completamente AS2 y OOP es utilizar el método estático "main". Para empezar en tu clase
necesitarías tener algo como:

classcom.myweb.MyClass{
privatevartimeLine_mc:MovieClip;
publicfunctionMyClass(m:MovieClip){
timeLine_mc=m;//guardamosreferenciaalMCdetrabajo//todotuyoapartirdeaquí:)
}
publicstaticfunctionmain(m:MovieClip):Void{
//aquínosllegacomoparámetroelMovieClipsobre//elque"trabajar"
varinstance:MyClass=newMyClass(m);
}
}

Luego, en línea de tiempo principal de tu fla, el siguiente código (que es lo que hace MTASC cuando compilamos con main):

importcom.myweb.MyClass;
MyClass.main(this);

Lo que estamos haciendo es llamar al método estático main y pasarle una referencia al MovieClip sobre el que queremos que trabaje la aplicación.

Lo bueno de utilizar este método o algo parecido es que no estamos haciendo nunca referencia explícita a "_root", por lo que si por la razón que sea, el swf en el que tenemos compilada la aplicación es cargado dinámicamente por otra película, no tendría ningún problema de referencias. En lugar de trabajar sobre la línea de tiempo principal, lo haría sobre la del MovieClip que haya sido cargada.

[ anterior ] [ siguiente ]

Comparte:

Lo que yo sé de AS2 #Entorno de trabajo

admin — Fri, 16 Mar 2007 02:29:24 +0000

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

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

Entorno de trabajo

>Indice de contenidos

Terminología básica

Antes de empezar a programar con AS2 hay estar familiarizado con algunos conceptos:

Classpath

Los classpath (puede haber varios) son necesarios para indicarle al compilador dónde está el código que quremos compilar.

Un classpath es una ruta que apunta a nuestras clases en el disco duro. La mejor opción es que guardes todas tus clases (y las de terceros) en el mismo sitio. Si no estás muy inspirado, algo como â€œC:\proyectos\as2\clasesâ€ puede valer (por pura precaución no pondría ni espacios ni caracteres raros). No es obligatorio tener todas las clases en el mismo sitio, pero yo diría que ayuda bastante a reutilizar código entre proyectos.

Namespace o espacio de nombres

Como es muy normal que distintos programadores llamen de la misma forma a una clase (â€œConfigâ€, â€œApplicationâ€, â€œWadusâ€) es necesario â€œalgoâ€ que permita esa coincidencia de nombres. Ese algo es un namespace.

Un namespace es un espacio reservado en el cual se guardan clases. â€œFísicamenteâ€ se traduce en una estructura de carpetas dentro del classpath. Por ejemplo, todas mis clases están en mi namespace que es tv.zarate.*. Es decir, dentro del classpath, hay una carpeta â€œtvâ€ y dentro de esa carpeta hay otra â€œzarateâ€. Dentro de â€œzarateâ€ es donde guardo todas mis clases.

Una vez ahí, hay total libertad para organizar la estructura de packages. Un package no es más que el conjunto de clases dentro de una carpeta. Es bastante normal tener un package para proyectos, otro para clases comunes, otro para efectos.... pero depende totalmente de cada programador.

A pesar de que no es imprescindible, sí que es muy recomendable tener un namespace â€œpropioâ€. Â¿Y cómo sabemos que es propio? Porque se suele utilizar un domino. Alquilen podría meter sus clases en la misma estructura, pero no es muy probable.

Import

Para utilizar una clase dentro de otra normalmente hay que importarla primero. Y para importarla hay que utilizar la palabra clave import seguida de el namespace completo de la clase que se quiere importar. Por ejemplo:

importtv.zarate.utils.Delegate;//importamoslaclaseDelegateclassA{
publicfunctionA(){
//para utilizarla, ya no tenemos que utilizar su ruta completa var callback:Function = Delegate.create (this, otherCallback)
}
}

Ahora, también es posible utilizar una clase sin namespace si está a la misma altura que el archivo .fla que se compila. Yo diría que es una mala opción, ya que si quisiéramos reutilizar la clase en otro proyecto habría que copiarla y pegarla a la altura del nuevo fla, con lo que reutilizar código se complica bastante.

Para más información sobre cuándo el compilador incluye una clase en un swf, ver en la sección de apuntes â€œÂ¿Cuándo se compila una clase?â€.

Constructor

El constructor de una clase es un método especial que es llamado automáticamente cuando se crea una instancia de la misma. En AS2 el constructor tiene que tener el mismo nombre que la clase. Sin embargo, NO es obligatorio tener constructor en la clase. Además, en el constructor no se puede definir el tipo devuelto. Ejemplo:

classA{
publicfunctionA():A{//erroralcompilar}
}

Compilador

Es un programa que se encargar de pasar nuestro código (en este caso, ActionScript) a un archivo .swf. Compiladores de AS2 hay varios, los más utilizados son el propio IDE de Flash y MTASC, del que hablaremos más luego.

El IDE de Flash

Para empezar a trabajar con el IDE, lo primero que tenemos que hacer es definir el classpath para nuestros proyectos. Se puede establecer el classpath para un fla determinado, pero yo creo que es una muy mala opción, especialmente si ese fla se va a compartir entre varias personas. Así que nos vamos a Editar > Preferencias > ActionScript > preferencias Action Script 2.0, seleccionamos agregar (el puntito de mira) y buscamos con el explorador el lugar en el que hemos puesto o vamos a poner todas las clases que vayamos a usar, tanto nuestras como propias.

El astuto lector habrá observado que por defecto hay 2 rutas creadas. Una es el directorio de la instalación de Flash que es donde se encuentran todas las clases de Macromedia. El otro simplemente es â€œ.â€, por eso a la hora de compilar el IDE siempre busca clases en la carpeta en la que se encuentra el fla.

AQUÃ VA UN MENSAJE PARA LOS INCAUTOS

El IDE de Flash da MUCHOS, MUCHOS problemas cuando se trabaja con un número elevado de clases, especialmente si están en un equipo que no es el nuestro (por ejemplo un servidor central). Esto es debido que para darle velocidad a la compilación el IDE cachea las clases que estamos utilizando. Eso que en teoría es una buena idea, está muy mal implementada. Y es más que normal que el compilador de errores raros que las 100 primeras veces piensas que es tu culpa y te vuelve loco. Conocedores del problema, desde Macromedia sacaron una extensión para limpiar la caché de clases antes de compilar (ver sección de enlaces).

Mi recomendación inicial es que directamente te pases a MTASC. Si no quieres o no puedes por lo menos échale un ojo a FLASC (Flash IDE + MTASC), seguro que te salva unas cuantas horas.

MTASC

Para quien no lo sepa, MTASC (MotionTween, ActionScript Compiler) es un compilador gratuito y abierto de AS2 desarrollado por Nicolas Cannasse. MTASC sólo compila AS2, así que no es posible utilizar #include o protos.

Para trabajar con MTASC no hay que hacer nada especial, simplemente pasarle como parámetro tu classpath con la opción cp. Sería algo así más o menos:

mtasc swf salida.swf header 200:200:0xff0000 cp â€œc:\ruta\a\tu\classpathâ€ main ClaseInicio.as

En la sección de Enlaces hay un pequeño tutorial de uso de MTASC y SWFMill para quien esté interesado.

[ anterior ] [ siguiente ]

Comparte: