Gus Mueller, el hombre detrás de Flying Meat, uno de los desarrolladores independientes de aplicaciones para Mac OSX más respetados, cuenta su historia en un post en el que desarrolla siete conceptos que considera básicos para llegar a alcancar el sueño de poder trabajar para uno mismo.
Una buena lectura para estas fechas, en las que se formulan tantos buenos propósitos.
Phillip Chu da las que entiende son las siete reglas principales para ser un programador efectivo. Habrá que ponerlo en la lisa de buenos propósitos para año nuevo...
El próximo jueves 19 de enero, como presentación oficial del portal generacionmac.com, especializado en el diseño y desarrollo de aplicaciones bajo plataformas Mac, se celebrará en Madrid el evento “Generación Mac: el futuro de la creación” con el mecenazgo de la Escuela Superior de Negocios y Estudios Internacionales – ESNE.
Este evento, dirigido a cualquier usuario Mac novel o profesional, es de carácter abierto y gratuito y tendrá lugar en las instalaciones de ESNE Madrid de 18h a 21h.
Debido a que el número de plazas es limitado, es necesaria inscripción previa a través del teléfono 91 555 25 28 o en el correo electrónico madrid@esne.edu, indicando sus datos personales y de contacto.
Los sufridos asistentes se tendrán que tragar un ladrillo de una hora titulado "¿Tienes media hora libre? desarrolla una aplicación con Core Data", a cargo de su seguro servidor. No digan que no estaban avisados.
Más información, en ESNE
Cada día que pasa es un día menos para la salida de FlashLite 2.0. Mosaic, la revista del Graduado Multimedia de la UOC se ha querido adelantar al feliz alumbramiento con un artículo en el que se repasa el estado actual de FlashLite, sus perspectivas de futuro, y se compara con los otros dos pesos pesados de la movilidad: C++ y J2ME.
¿La conclusión final?: va a ser necesario empezar a tomar en serio a FlashLite.
...y asegurarse un trabajo de por vida. Un link de hace bastante tiempo, que habÌa perdido, y que acabo de reencontrar:
Objective-C, como cualquier programador iniciado en el mismo sabe, es un lenguaje que, a diferencia de java o actionscript, no tiene recolector de basura, no maneja la memoria por sí mismo, sino que es responsabilidad del programador el liberar los recursos que haya utilizado con anterioridad.
El manejo de memoria no es especialmente complicado, aunque sí requiere atención y un toque de rigurosidad por parte del programador. Eso no evita, que haya situaciones en las que sea fácil producir leaks de memoria, al no preveer alguna situación especial en el programa, como por ejemplo, al lanzar una excepción.
Bien, pues sirvan los dos párrafos anteriores como introducción a este post de Chris Hanson titulado Cocoa memory management & exceptions
Sí, design-nation sale al quiosco. En el número de noviembre de MacWorld España, aparece publicado un artículo escrito por éste su seguro servidor. Se trata de el Primer Contacto con el Macromedia Studio 8.
Pese a ese artículo, la revista, como siempre, está llena de contenidos interesantes, como una revisión de los servicios .Mac, un informe sobre qué Mac o que iPod elegir (aunque eso es fácil: todos) o un artículo sobre cómo evitar los problemas con iMove HD.
Lo dicho, en el MacWorld de Noviembre.
A estas alturas seguro que has oído hablar (como mínimo) de la serie Head First, en concreto de Head First Design Patterns que probablemente sea la mejor introducción para entender los patrones de diseño.
La semana pasada, cuando estaba buscando otras cosas en amazon, me encontré con esto: Head First Design Patterns Poster.
Como su propio nombre indica, es un poster (bastante grande, por cierto) que contiene los gráficos (extraídos del libro), no los diagramas UML de los patrones, sino los gráficos de los ejemplos del libro, así como el número de la página en la que aparece ese patrón tanto en el Gang of Four como en el Head First Design Patterns.
Resume de forma visual 18 patrones, y ahora mismo luce enfrente de mis ojos clavado en la pared...
(Por cierto, ninguno de los enlaces es patrocinado, y por tanto NO me llevo comisión).
El Studio 8 de Macromedia ya est· disponible en castellano. Y sÌ, hay licencia para profesores y estudiantes por 85Ä m·s IVA.
Ayer preguntaba por el nombre de un patrón.
El patrón era el Strategy.
EDITADO: El patrÛn es el Strategy. Por tanto, el tÌtulo del post deberÌa ser "Un ejemplo el patrÛn Strategy en actionscript"
El Profesor Dispar ha estado disfrutando de unas merecidas vacaciones tras conquistar el mundo (sÌ, desde la ˙ltima vez que tuvimos noticias de Èl, ha conseguido llevar a buen puerto sus malÈficos planes).
Pero el dÌa a dÌa de dominar el mundo le est· matando de aburrimiento. El Profesor Dispar echa de menos los viejos tiempos, cuando nadie le comprendÌa, cuando podÌa odiar a todos los lÌderes del mundo porque le ignoraban... Ahora pasa la mayor parte del dÌa haciendo papeleo, y aÒora los dÌas en los que se podÌa dar una vuelta por los campamentos de sus tropas y confraternizar con ellos, contar chistes, tomar unas cervecitas...
AsÌ que, en un arranque de genio (malvado, claro), ha decidido que, para matar el aburrimiento, quiere ver un desfile cada dÌa. Mejor dicho, un desfile diferente cada dÌa. Un dÌa le pedir· a su Mariscal que le prepare un desfile con los chicos de la compaÒÌa B, otro dÌa querr· que desfilen los soldados cuyo nombre contenga una P... ahhh, los genios del mal...
Acabamos de actualizar los posts de los tres ejemplos de flash 8 que publicamos en su día, añadiendo el código fuente de los mismos:
Estaba escribiendo un comentario a este post de Carlos Rovira, pero como me estaba quedando demasiado largo, he preferido hacer un post aparte.
Está habiendo cierta sensación de "no es para tanto" en un sector de la "comunidad" en relación con la nueva versión de flash.
No sé, no es nada que no se supiera. Siempre se ha dicho desde Macromedia que éste iba a ser un release "para diseñadores" ( aunque probablemente no fuera esas las palabras exactas ).
No hay nuevo set de componentes, cierto. Pero de entre las novedades que sí hay, quisiera resaltar tres que creo eran fundamentales:
Hay más cosas, por supuesto. Los filtros aplicables a movieclips, la subida de archivos...
Para ser un release orientado a los creativos, se han implementado muchas cosas de las que también nos vamos a beneficiar los desarrolladores. Y esto es flash, se trata de hacer las cosas bonitas, muy muy bonitas...
No hay set de componentes nuevo. En mi opinión, porque necesitan una reescritura desde cero, algo que ahora no se podía asumir. Todo llegará.
Si se programa en varios lenguajes, va a llegar un momento en el que las distintas sintaxis se van a cruzar.
Syntax across languages es un proyecto de sourceforge que pretende documentar cÛmo se hacen las cosas en distintos lenguajes. Por ejemplo, cÛmo se declara una funciÛn o un bloque if.. else o un bucle en java, C, C#, C++, Perl,....
En todo caso, aunque sÛlo sea por satisfacer la curiosidad de ver cÛmo hacen las cosas "los otros", no viene mal echarle un vistazo.
Via __resolve
Arrastra el sol alrededor de la tierra y ver·s cÛmo la sombra que Èsta proyecta cambia. Necesitar·s la flash player 8 public beta
Para este ejemplo, he utilizado algunas de las nuevas clases de flash 8, como los filtros glow, dropshadow y bevel, asÌ como alguna de las nuevas clases para c·lculos geomÈtricos.
ACTUALIZACI”N 20/9/05: Descarga el cÛdigo fuente
Haz click en el fondo
Es necesario el flash player 8:
http://www.macromedia.com/software/flashplayer/public_beta/
ACTUALIZACI”N 20/9/05: Descarga el cÛdigo fuente
Haz click en el fondo
ACTUALIZACI”N 20/9/05: Descarga el cÛdigo fuente
Ya se ha anunciado la nueva versiÛn de flash, que se va a llamar Flash 8. TambiÈn se ha anunciado Dreamweaver 8, y Macromedia Studio 8.
Como la noticia estar· dando la vuelta a los blogs durante todo el dÌa, probablemente lo mejor sea ir directamente al MXNA y leer todos los posts sobre el tema.
En todo caso, lo m·s parecido a un anuncio oficial puede ser esto:
Si recuerdan, aquÌ ,les explicaba el motor para el desarrollo de aventuras gr·ficas en Flash. Bien,entre aventuras, reediciones, traducciones, ..ya he perdido la cuenta del n˙mero de cdroms que han salido, todos sin problemas. ø Todos ?. No. El otro dÌa, un cdrom, empezÛ a dar problemas. Por requerimientos del proyecto, debe funcionar en un pentium II a 300Mhz. Termino de exportar el cdrom en mi m·quina ( Pentium IV ) y funciona perfÈctamente, pero al llevarlo a las m·quinas de testing ( Pentium II con W98, Pentium con Linex, Mac G3 ),fallaba en todas. Bueno, no es que fallase, es que iba muy muy lento. ø cu·l es el problema ? ø porquÈ si todos los cdroms funcionan bien, este da problemas ?.
Comienza la fase de an·lisis del problema, y se descarta problemas de la programaciÛn ( todos los cdroms llevan el mismo cÛdigo ) .
Como el cliente ha pedido unos cambios en unas animaciones, empiezo a pensar que uno de estos cambios en la animaciÛn de inicio o en la de fin del juego, hacen que algo falle. ASÌ pues, empiezo a probarlo sin una de las animaciones, sin la otra, sin ninguna de las dos, rehaciendo todo el fla desde cero, etc... ( Bien, hay que explicar, que cada prueba supone, exportar el fla, crear un instalador con zinc estudio, generar en una imagen ISO un disco hÌbrido pc/mac, sacarlo a disco fÌsico, ....en total cada cambio unos 45 minutos mÌnimo hasta poder probar en las m·quinas de testing ) y nada que no funciona.
Es entonces cuando me doy cuenta que nada m·s arrancar el cdrom, la primera pantalla que aparece, es la de login, y que al introducir tus datos, parece que incluso le cuesta aparecer en pantalla, es decir, escribo una "e" y como que pasan unos milisegundos hasta que aparece en pantalla. Lo justo para que parezca algo raro. AsÌ pues, se me ocurre que el problema puede estar en un swf que se carga nada m·s arrancar el cdrom con la configuraciÛn de los men˙s, los textos que se deben mostrar en todo el cdrom etc..( este swf se genera a partir de todos los xml con los que se desarrolla el juego ) . AsÌ pues le abro,y ........ el *+«?ø{ swf tenÌa dos frames, dos puÒeteros frames, el primer frame en el que se declaraban las 300 variables( de tipo XML ) de configuraciÛn y textos del cdrom , y un segundo fotograma vacÌo. Lo que hacÌa que se estuviesen definiendo esas 300 variables ( aproximadamente ) 6 veces por segundo, y claro, el juego se tostaba.
En fÌn, tras averiguar la causa del problema sÛlo se me ocurrÌa acordarme de la madre del F5, del fotograma de los...
AsÌ que la moraleja es...Tener cuidado con los fotogramas vacÌos, que uno sÛlo puede hacer que vuestras 8000 lÌneas de cÛdigo no sirvan para nada.
Conquistar el mundo no es f·cil. Nada f·cil. Yo lo sÈ, t˙ lo sabes, incluso el Profesor Dispar lo sabe.
El Profesor se siente preparado para llevar a cabo su malvado plan. Tiene el conocimiento teÛricos, tiene los conocimientos pr·cticos, tiene un plan, tiene hasta unas gafas de sol nuevas, pero °hay tantos detalles que pulir antes de lanzarse a la conquista del mundo!.
En episodios anteriores, hemos visto cÛmo el Profesor ha implementado el patrÛn prototype ( para crear su ejÈrcito de clones -°anda, acabo de caer!- ), el patrÛn extensiÛn objects ( para asignarles sus roles ), el patrÛn command ( para asignarles las Ûrdenes ), y el patrÛn observer ( para implementar el sistema de comunicaciones ). Parece que el Profesor Dispar ha estado bastante ocupado implementando patrones, pero ha sido suficiente?. NO!! ( muhahahahahahhaha ).
Continuar leyendo "Un ejemplo del patrÛn memento ( la versiÛn actionscript )" »
No te repitas. En cuanto escribes el mismo cÛdigo m·s de una vez, est·s empezando a meterte en problemas
AquÌ tienes un ejemplo.
Estoy trabajando en una aplicaciÛn en la que voy a utilizar los componentes de UI. Es una aplicaciÛn Modelo-Vista-Controlador, por lo que la vista estar· totalmente desacoplada de la lÛgica de la aplicaciÛn
La aplicaciÛn va a tener m·s de una vista ( hay varias "pantallas" diferentes en las que tengo que mostrar los datos de diferentes formas ), por lo que he decidido que lo mejor ser· escribir una clase diferente para cada una de esas vistas.
Por tanto, cada vista attachear· un movieclip, que es el que contiene realmente la "pantalla" con los elementos interactivos ( botones, datagrid, etc ). Todas esas vistas extienden de una clase que implementa cierta funcionalidad com˙n ( emisiÛn de eventos y alguna cosilla m·s ). Por tanto, no extender·n de movieclip ( aparte de por razones un poco m·s abstractas, aunque Èste no es el momento para discutir eso ). A lo que vamos.
Adem·s, resulta ( todo son facilidades ) que por ahora no tengo los gr·ficos definitivos ( vamos, que me lo estoy pintando yo ). A˙n m·s, si al final el presupuesto da para ello, tendrÈ que desarrollar mis propios componentes.
Bien, pues una vez puestos en antecedentes, imagina que arranca la aplicaciÛn. Lo primero con lo que se va a encontrar el usuario es con una pantalla de login
Como puedes ver en la captura, a) m·s me vale que me vaya bien en esto de la programaciÛn, por que lo que es en la parte gr·fica...; b) la pantalla contiene un componente ( el botÛn ).
La clase que maneja esa pantalla ser·:
import mx.utils.Delegate;
class LoginView
{
private var timeline : MovieClip;
private var loginScreen: MovieClip;
function LoginView( tl: MovieClip )
{
this.timeline = tl;
}
public function init( )
{
this.loginScreen = this.timeline.attachMovie( "LoginScreen", "LoginScreen",
this.timeline.getNextHighestDepth( ), { _x: 0, _y: 0 } );
this.loginScreen.loginBtn.label= "Go!";
this.loginScreen.loginBtn.addEventListener( "click", Delegate.create( this, click ) );
}
private function click( )
{
trace( "click" );
}
}
Y cuando quiera que aparezca, harÈ algo como:
var loginView: LoginView = new LoginView( this );
loginView.init( );
Y el botÛn no va a funcionar. Ni siquiera va a mostrar el texto que le he asignado. Tras unos minutos de buscar en google, un poco de sentido com˙n, y un poco menos de conocimiento de la plataforma, he llegado a la conclusiÛn de que el botÛn no se inicializa a tiempo, y que tal vez deberÌa dejar pasar un frame para asignar el texto y el click.
import mx.utils.Delegate;
class View
{
private var timeline : MovieClip;
private var loginScreen: MovieClip;
function View( tl: MovieClip )
{
this.timeline = tl;
}
public function init( )
{
this.loginScreen = this.timeline.attachMovie( "LoginScreen", "LoginScreen",
this.timeline.getNextHighestDepth( ), { _x: 0, _y: 0 } );
var theView: View = this;
this.loginScreen.onEnterFrame = function( )
{
theView.initButton( );
delete this.onEnterFrame;
}
}
private function initButton( )
{
this.loginScreen.loginBtn.label= "Go!";
this.loginScreen.loginBtn.addEventListener( "click", Delegate.create( this, click ) );
}
private function click( )
{
trace( "click" );
}
}
Y funciona. Pero esta soluciÛn no huele demasiado bien ( y no sÛlo por el truqui del scope ). Voy a tener que hacer bastantes pantallas ( alrededor de una docena ), asÌ que voy a tener que repetir ese cÛdigo en todas ellas. Desde luego, podrÌa subclasificar, pasar ese cÛdigo a una clase base, pero no voy a tener el mismo n˙mero de botones en todas las pantallas, luego tampoco tendrÌa mucho sentido subclasificar para luegosobreescribir, y adem·s, sÛlo podrÌa utilizar ese cÛdigo en subclases de la clase base que creara, con lo cual no iba a tener demasiada flexibilidad, que digamos. Y adem·s, mis vistas ya extienden de otra clase base.
E incluso puede ser peor, porque es probable que tenga que cambiar esos componentes por unos mÌos ( o no, que a˙n no lo sÈ ). AsÌ que es m·s que probable que ese cÛdigo tenga que cambiar en un futuro no muy lejano
AsÌ pues, estoy repitiendo cÛdigo, y adem·s, es probable que ese cÛdigo tenga que cambiarlo en breve. øCÛmo lo puedo resolver?. Pues encapsulando ese cÛdigo dentro de su propia clase.
Para empezar, usarÈ un callback que ya he utilizado m·s veces:
class Callback
{
private var callbackObjVal: Object;
private var callbackMethodVal: String;
public function Callback( objParam: Object, methodParam: String )
{
this.callbackObjVal = objParam;
this.callbackMethodVal = methodParam;
}
public function fire( parameter: Object ): Object
{
return this.callbackObjVal[ this.callbackMethodVal ]( parameter );
}
}
La clase encargada de manejar el botÛn ser·:
class ButtonHandler
{
public static function initButton( mc: MovieClip, callback: Callback )
{
var cb: Callback = callback;
mc.onEnterFrame = function( )
{
cb.fire( );
delete this.onEnterFrame;
}
}
}
Y la utilizarÈ de la siguiente forma:
import mx.utils.Delegate;
class View
{
private var timeline : MovieClip;
private var loginScreen: MovieClip;
function View( tl: MovieClip )
{
this.timeline = tl;
}
public function init( )
{
this.loginScreen = this.timeline.attachMovie( "LoginScreen", "LoginScreen",
this.timeline.getNextHighestDepth( ), { _x: 0, _y: 0 } );
ButtonHandler.initButton( this.loginScreen, new Callback( this, "initButton" ) );
}
private function initButton( )
{
this.loginScreen.loginBtn.label= "Go!";
this.loginScreen.loginBtn.addEventListener( "click", Delegate.create( this, click ) );
}
private function click( )
{
trace( "click" );
}
}
øUna soluciÛn excesivamente compleja?. Puede, pero es la que m·s me ha satisfecho, porque es la que aporta m·s flexibilidad. Si tengo que cambiar la forma en la que manejo los botones, sÛlo tengo que cambiar la implementaciÛn de un mÈtodo en una clase. Estoy programando pensando en el interfaz, y no en la implementaciÛn.
Est· desencadenado. El primer ataque ha sido lanzado. El profesor Dispar ha dado las Ûrdenes a sus huestes para dominar el mundo. En post anteriores hemos visto como el profesor Dispar ha conseguido clonar cualquier animal ( con gran predilecciÛn por ovejas y vacas ) utilizando un patrÛn prototype, ha conseguido darlas un rol din·micamente con el patrÛn extension objects, y ha repartido las Ûrdenes con un patrÛn command.
Pero como ya sabemos, el profesor Dispar est· loco, pero no es idiota. Sabe, que algo puede salir mal, que un pequeÒo detalle puede truncar sus planes de dominar el mundo. Y tambiÈn sabe que una retirada a tiempo es una victoria.
Continuar leyendo "Un ejemplo el patrÛn observer (la versiÛn actionScript)" »
Todo est· preparado. Las ovejas y las vacas han sido clonadas y sus roles han sido asignados. Es el momento perfecto para que el Profesor Dispar lance su ataque final. °°°°°Ha llegado el momento de conquistar el mundo!!!!
øPero cÛmo dar· el Profesor Dispar a sus tropas la orden de atacar?
øRecuerdas al Professor Dispar?. øRecuerdas sus malvados planes para dominar el mundo?.
Hoy veremos cÛmo el patrÛn Extension Objects ( o "cÛmo cambiar el interfaz que implementa una clase en tiempo de ejecuciÛn" ) ha ayudado al Profesor Dispar. Pero no va a ser una tarea f·cil, porque este patrÛn es muy complejo, pero øquiÈn dijo que ser un genio del mal fuera f·cil?.
Continuar leyendo "Un ejemplo del patrÛn Extension Objects" »
Desde finales de Diciembre y hasta finales de febrero, he estado desarrollando un motor para la creaciÛn de aventuras gr·ficas, realizado Ìntegramente con ActionScript 2.0 .
Por requerimientos del cliente, las aventuras gr·ficas debÌan ser completamente ( tanto los objetos que aparecen en pantalla como la lÛgica del juego ) configurables desde archivos XML. Adem·s, otros requerimientos eran la utilizaciÛn de diferentes perspectivas visuales en las escenas ( la aventura gr·fica no podÌa estar completamente realizada en una sola perspectiva, tÌpicamente isomÈtrica ) y adem·s debÌa simular un "efecto de 3d" en las escenas en que fuese necesario.
Es decir, un motor en el que se carga la lÛgica de cada escena de un archivo xml, en el que debe funcionar la escena independientemente de que sea una perspectiva frontal, lateral, una habitaciÛn de dos pisos etc..., y en la que habÌa que desarrollar un sistema que permitiese al personaje pasar por delante y/o detr·s de los objetos que aparecen en pantalla ( por ejemplo una mesa en el medio de una habitaciÛn ) en funciÛn de su posiciÛn ( que claro, depende de la perspectiva ). Evidentemente, el motor se desarrollÛ antes que muchos diseÒos de escenas, por lo que debÌa ser lo suficientemente flexible como para permitir que en pantalla hubiese de 0 a n objetos, que cada uno de estos objetos pudiese estar en cualquier coordenada de pantalla ( objetos en primer plano, objetos a media distancia, objetos en lÌnea del horizonte ) y que el personaje pudiese interactuar con ellos correctamente.
Continuar leyendo "Motor para aventuras gr·ficas en AS 2 y XML" »
Sabemos que se puede asignar una clase AS2 a cualquier movieclip que se encuentre en la librerÌa. Si esa clase extiende movieclip, cuando se atachea ( menudo palabro ) el clip se materializa una instancia de esa clase. Pero ni siquiera hace falta hacer el attachmovie. Con colocar el clip en el stage en tiempo de diseÒo es suficiente, la instancia de la clase se materializar· cuando el cabezal llegue a ese frame. Esto puede facilitar el trabajo cuando se est· creando una interfaz de usuario, no hay m·s que colocar el movieclip en el stage y *magia*, se tiene una instancia de la clase asociada.
Imaginemos que hay que crear un interfaz parecido a Èste:
Continuar leyendo "Un caso en el que no se deberÌa heredar de movieclip" »
Probablemente ya lo hayas oÌdo ( mejor dicho, leÌdo ), pero Macromedia ha convocado un concurso para decidir cu·l es la mejor aplicaciÛn para FlashLite. °Y hay buenos premios!
Los detalles sobre el concurso est·n aquÌ:
http://www.macromedia.com/mobile/special/contest/
Obviamente, necesitar·s el player de Flash Lite para probar tu aplicaciÛn. Puedes pedirlo enviando un email a flashlite_contest@macromedia.com, invluyendo el modelo del dispositivo y el IMEI del mismo.
Si quieres saber si tu dispositivo est· soportado, aquÌ tienes la lista:
http://www.macromedia.com/mobile/supported_devices/#tmobile
°Corre!. °El plazo de presentaciÛn termina el 1 de febrero!.
Continuar leyendo "[PPC] AplicaciÛn del modelo-vista-controlador a una aplicaciÛn para PocketPC" »
Las cuatro palabras de moda en el mundo flash son ìProgramaciÛn Orientada a Objetosî, sobre todo desde que hace ya casi aÒo y medio se lanzara el Flash MX 2004, y con Èl el AS2.
Todos hemos oÌdo hablar de los beneficios que la programaciÛn orientada a objetos va a traer a nuestro trabajo diario, de lo f·cil que nos va a resultar mantener nuestros programas si escribimos muchas clases, de lo bueno que es escribir clases, en vez de poner cÛdigo en botones, y de lo importantes que son la encapsulaciÛn y el polimorfismo. Pero, øes realmente asÌ?. øDe verdad la programaciÛn orientada a objetos nos puede facilitar el trabajo?.
Continuar leyendo "Algunos beneficios pr·cticos de la programaciÛn orientada a objetos" »
Es, m·s o menos, el tÌtulo de una discusiÛn muy interesante el el wiki de c2. No sÛlo por la discusiÛn en sÌ, sino tambiÈn por la cantidad de enlaces a otros artÌculos que se aportan.
øPuede ser peligroso utilizar demasiado los patrones de diseÒo?. øPuede hacer que nuestros sistemas sean innecesariamente complejos?. øO son la mejor soluciÛn a muchos problemas?
Aparte de las consideraciones expuestas en el post anterior, hay un par de razones para favorecer la composiciÛn sobre la herencia que probablemente sean de mucho m·s peso.
En primer lugar, la herencia no permite cambiar las implementaciones de las clases heredadas en tiempo de ejecuciÛn, y adem·s, rompe la encapsulaciÛn, ya que la clase base es visible a travÈs de las clases heredadas.
Continuar leyendo "En caso de duda, composiciÛn ( y III )" »
øQuÈ pasa si nuestra jerarquÌa de clases es muy profunda o est· muy extendida?. Pues que corremos un riesgo muy grande de tener problemas si cambia el interfaz de la superclase.
Seguimos teniendo a nuestros programadores y nuestros camioneros levant·ndose por las maÒanas, yendo a trabajar, y volviendo a casa por las noches. Supongamos que en la clase base ( Persona ) hay un mÈtodo como Èste:
La forma en la que todos nos adentramos en el mundo de la programaciÛn orientada a objetos suele ser parecida. Tendemos a depender en exceso de la herencia, a realizar jerarquÌas de clases muy cerradas y muy estrictas, a solucionar cualquier problema, por pequeÒo que sea, a base de crear clases hijas particularizadas para ese problema. øPero es Èsa la mejor forma de organizar nuestro cÛdigo?
Hace poco, alguien me dijo que discutir sobre herencia y composiciÛn era como discutir sobre pc vs mac. Yo creo que no es asÌ. Voy a intentar explicar por quÈ
El patrÛn Abstract Factory es uno de los patrones de construcciÛn. B·sicamente, proporciona una interfaz que permite crear familias de objetos relacionados entre sÌ, sin especificar ( ni por lo tanto, conocer a priori ) sus clases concretas.
Voy a intentar explicarlo con un ejemplo un poco m·s ìrealî. Supongamos que quiero decorar mi casa. Puedo elegir entre dos lÌneas de decoraciÛn distintas ( en este caso, ìModernaî, o ìCl·sicaî ). En principio sÛlo voy a comprar las puertas y una televisiÛn.
øPor quÈ implementar una factorÌa abstracta para resolver el problema?. Voy a intentar explicarlo sobre la marcha. En primer lugar voy a suponer que en mi ciudad hay dos tiendas de decoraciÛn, la que vende elementos decorativos cl·sicos, y la que vende elementos decorativos modernos. Adem·s, supondrÈ que las dos tiendas venden los mismos elementos decorativos ( televisores y puertas ).
Bien, si yo quiero comprar una televisiÛn, independientemente de lo moderna o cl·sica que sea, voy a la tienda y digo ìquiero una televisiÛnî. Adem·s, una televisiÛn, sea moderna o cl·sica, me permite hacer las mismas cosas: encenderla, apagarla, subir y bajar el volumen, aunque no se haga de la misma forma ( en la moderna, lo hago con el mando a distancia, en la antig¸a me tengo que levantar ).
Por lo tanto, ya sÈ que tengo que ir a la tienda, y pedir una televisiÛn. Pero tambiÈn puedo encargarle a un transportista que me traiga una televisiÛn moderna. Yo no tengo que decirle nada m·s que eso, porque es el transportista es el que se encarga de pensar ìvale, me ha dicho que quiere una tele moderna, por tanto, tengo que ir a la tienda donde venden las teles modernas, y pedir una teleî. Pues el transportista es la factorÌa abstracta. Yo, como cliente, le pido una televisiÛn moderna, y sÈ que voy a obtener una televisiÛn de plasma de 42î que puedo manejar con el mando a distancia adjunto. øQuÈ cÛmo la ha conseguido el transportista?: no me importa. SÛlo me importa que me la traiga.
Antes de empezar a implementarlo en actionScript, una consideraciÛn teÛrica importante. ActionScript no implementa clases abstractas. Es cierto que se pueden simular, pero no est·n implementadas, por lo que yo no voy a basar la arquitectura de este patrÛn en una clase abstracta, sino en un interfaz.
Empecemos. Hemos dicho que tanto si voy yo en persona a la tienda, como si hablo con un transportista, lo ˙nico que tengo que hacer es decir "quiero una tele". Por lo tanto, tanto las tiendas como el transportista van a implementar un interfaz com˙n ( si fuÈramos estrictos, deberÌan heredar de una misma clase abstracta que implementara ese interfaz ).
El interfaz ser·:
import net.designnation.patterns.AbstractFactory.*
interface net.designnation.patterns.AbstractFactory.IFactoryActions
{
public function getTV( ): ITVActions;
public function getDoor( ): IDoorActions;
}
Como puede verse, hay dos acciones posibles: getTV, y getDoor ( es decir, tr·eme una tele, y tr·eme una puerta ).
Por tanto, las dos tiendas ser·n algo asÌ:
import net.designnation.patterns.AbstractFactory.*
class net.designnation.patterns.AbstractFactory.ModernShop implements IFactoryActions
{
function ModernShop( )
{
trace( "He elegido la tienda moderna" );
}
public function getTV( ): ITVActions
{
return new BrandNewTV( );
}
public function getDoor( ): IDoorActions
{
return new ModernDoor( );
}
}
import net.designnation.patterns.AbstractFactory.*
class net.designnation.patterns.AbstractFactory.ClassicShop implements IFactoryActions
{
public function ClassicShop( )
{
trace( "He elegido la tienda cl·sica" );
}
public function getTV( ): ITVActions
{
return new OldTV( );
}
public function getDoor( ): IDoorActions
{
return new ClassicDoor( );
}
}
Como puede verse, las dos tiendas implementan el interfaz IFactoryActions ( implementan dos mÈtodos llamados getTV y getDoor, que devolver·n respectivamente, una televisiÛn y una puerta ).
AtenciÛn. Vamos a ver con m·s atenciÛn el mÈtodo getTV( ).
public function getTV( ): ITVActions
{
return new OldTV( );
}
øInstanciamos una clase OldTV pero el mÈtodo devuelve un interfaz?. Cierto. Eso es lo que nos permite tratar a todas las televisiones por igual, sean modernas, antig¸as, o de gas. Porque lo que a nosotros nos interesa es poderle decir a la televisiÛn: ìenciÈndeteî, y que Èsta lo haga, como sea, pero que lo haga. Eso lo logramos haciendo que las dos clases que representan televisores implementen una interfaz com˙n:
interface net.designnation.patterns.AbstractFactory.ITVActions
{
public function pumpUpTheVolume( );
public function shutUp( );
}
Y por tanto, la televisiÛn moderna ser·:
import net.designnation.patterns.AbstractFactory.*
class net.designnation.patterns.AbstractFactory.BrandNewTV implements ITVActions
{
function BrandNewTV( )
{
trace( "He recibido mi televisiÛn de plasma de 42 pulgadas" );
}
public function pumpUpTheVolume( )
{
trace( "por supuesto, espera que busco el mando" );
}
public function shutUp( )
{
trace( "Presionando esta tecla, el sonido se silencia" );
}
}
Mientras que la cl·sica es:
import net.designnation.patterns.AbstractFactory.*
class net.designnation.patterns.AbstractFactory.OldTV implements ITVActions
{
function OldTV( )
{
trace( "Me he comprado una tv vieja" );
}
public function pumpUpTheVolume( )
{
trace( "Como no tiene mando a distancia, me tengo que levantar a subir el volumen" );
}
public function shutUp( )
{
trace( "Como no tiene mando a distancia...." );
}
}
Lo mismo pasarÌa con las puertas. Sea moderna o antigua, la puerta tiene dos posibles acciones, se puede abrir, y se puede cerrar, por lo tanto las dos clases que representan a puertas implementan un interfaz com˙n:
interface net.designnation.patterns.AbstractFactory.IDoorActions
{
public function open( );
public function close( );
}
La puerta moderna:
import net.designnation.patterns.AbstractFactory.*
class net.designnation.patterns.AbstractFactory.ModernDoor implements IDoorActions
{
function ModernDoor( )
{
trace( "Constructor de la puerta moderna" );
}
public function open( )
{
trace( "Abriendo la puerta moderna" );
}
public function close( )
{
trace( "Cerrando la puerta moderna" );
}
}
Y la cl·sica:
import net.designnation.patterns.AbstractFactory.*
class net.designnation.patterns.AbstractFactory.ClassicDoor implements IDoorActions
{
function ClassicDoor( )
{
trace( "ClassicDoor constructor" );
}
public function open( )
{
trace( "Puerta cl·sica abierta " );
}
public function close( )
{
trace( "Puerta cl·sica cerrada" );
}
}
Recapitulemos. Tenemos dos tiendas. Ambas venden puertas y televisores. La tienda cl·sica vende puertas y televisores cl·sicos, y la tienda moderna vende puertas y televisores modernos.
Bien, pues nuestro transportista serÌa la abstract factory:
import net.designnation.patterns.AbstractFactory.*
class net.designnation.patterns.AbstractFactory.AbstractFactory
{
public static var MODERN : Number = 1;
public static var CLASSIC : Number = 2;
public static function getFactory( shopType: Number ): IFactoryActions
{
if ( ( shopType & MODERN ) == MODERN )
{
return new ModernShop( );
}
if ( ( shopType & CLASSIC ) == CLASSIC )
{
return new ClassicShop( );
}
}
}
Esta clase implementa el mismo interfaz que las dos tiendas. Por tanto, yo le dirÈ, "oye, quiero una tele moderna", y me olvidarÈ de todos los detalles del proceso. Al final, tendr· algo a lo que podrÈ subir y bajar el volumen,Ö. øCÛmo?:
import net.designnation.patterns.AbstractFactory.*
var factory: IFactoryActions = AbstractFactory.getFactory( AbstractFactory.MODERN );
var myTV: ITVActions = factory.getTV( );
myTV.pumpUpTheVolume( );
var myDoor: IDoorActions = factory.getDoor( );
myDoor.close( );
Flashblog ha nacido con el espÌritu de ofrecer un medio tÈcnicamente avanzado, basado en tecnologÌas como Macromedia Flash y php, donde las personas puedan exponer libremente sus pensamientos.
Flashblog funciona con cualquier configuraciÛn b·sica de Apache/Php(4)/MySQL, y sin instalaciÛn de ninguna librerÌa especial. Necesita lÛgicamente Flash MX 2004 y su Player 7 para soportar la carga de contenido gr·fico, y lo mejor de todo, es que se publicar· como OpenSource.
Flashblog se publicar· prÛximamente, pero por ahora podeis obtener m·s informaciÛn en su web: Flashblog.org