Algunos beneficios pr·cticos de la programaciÛn orientada a objetos
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?.
Pensemos en que tenemos que hacer un sitio web en el trabajo, que presenta nada m·s cargarse dos campos de texto y un botÛn, para que el usuario introduzca su nombre de usuario y contraseÒa y envÌe esos datos a un script en php en el servidor, que compruebe si dicho usuario puede visualizar el resto de la web.
En principio, se me ocurren tres posibles formas de realizar ese trabajo.
1.- La forma ìcl·sicaî: Colocamos en el stage los campos de texto, como texto input, y colocamos un botÛn de ìEnviarî ( botÛn o movieclip ). Entonces, escribimos el siguiente script en el botÛn:
on( release )
{
_root.getURL( ìmiscript.phpî, "_self", ìGETî );
}
øCu·les son las ventajas de este mÈtodo?. La m·s importante: la rapidez. En dos minutos hemos resuelto la pantalla de login.
Pero, øquÈ pasa si tenemos que implementar pantallas parecidas a Èsta en todas las webs que hacemos?. Pues tendrÌamos que coger ese cÛdigo, e irlo pegando en todos los botones de todas las webs que vayamos haciendo. ø Y si de repente cambia la direcciÛn del php?. Pues habr· que abrirse todos los fla, e ir cambiando uno por uno los scripts de todos los botones.
Por tanto, el tiempo de desarrollo es mÌnimo, pero el mantenimiento puede ser un infierno.
2.- Centralizar el cÛdigo en un frame, o mejor a˙n, extraer ese cÛdigo centralizado a un archivo *.as
Sigamos pensando en el ejemplo anterior. Si en vez de colocar cÛdigo directamente en el botÛn, damos nombre de instancia a ese botÛn ( ìenviarBtnî ), podemos escribir un fichero as con este cÛdigo:
enviarBtn.onRelease = function( )
{
_root.getURL( ìmiScript.phpî, "_self", ìGETî );
}
Ahora tan sÛlo tendrÌamos que hacer un include de ese archivo as en el frame donde se presenta esa pantalla de login, y problema resuelto. Y si, adem·s, tenemos que hacer m·s webs parecidas, tan sÛlo tendremos que incluir ese archivo as, y problema resuelto. Si cambia la direcciÛn del php, lo cambiamos en el as, y todas las webs estarÌan actualizadas.
øPero quÈ pasa si no todas las webs que hagamos deben enviar los datos al mismo php?. Incluso, es posible, que ni siquiera todos sean phps, puede que haya asp, jsp, etc. O incluso, puede que en algunas webs haya que hacer alguna cosa con esos datos antes de enviarlosÖ.
Hemos mejorado el mantenimiento, pero hemos perdido mucha flexibilidad.
3.- La soluciÛn orientada a objetos. øY si dividimos el proceso completo en pequeÒas ìentidadesî, cada una encargada de una tarea pequeÒa ( y sÛlo una tarea )? ø Y si hacemos esas entidades de manera que sean lo m·s independientes entre sÌ, de modo que si debemos cambiar una, ese cambio no afecte a las dem·s?. Mejor a˙n, øy si la forma en la que cada una de esas pequeÒas entidades lleva a cabo su tarea, es totalmente desconocida para el resto de las entidades que forman el programa?.
Supongamos que tenemos una unidad que se encarga de decirle al botÛn que, cuando sea clickeado, emita un evento con los datos de esos campos de texto ( o que le diga a esa entidad que le pase los datos a otra entidad distinta ). Supongamos que hay otra entidad que est· esperando a recibir datos ( los que sean, y en el formato que sean ), para pas·rselos a una tercera entidad, que tan sÛlo debe encargarse de enviar los datos que le pasen a un script en servidor ( que tambiÈn se le puede pasar como par·metro ).
Bien, pues cada una de esas entidades serÌa una clase. TendrÌamos, por tanto, una clase encargada de manejar la interacciÛn del usuario ( lo que pasa cuando se hace clic en el botÛn ) y de hacer llegar los datos de usuario y password a otra clase que, a su vez, se los pasa a otra clase encargada de enviarlos a servidor.
øQuÈ pasa si cambia el nombre del script que debe recibir esos datos?. Nada, porque la clase intermedia ( la que recibe los datos y se los pasa a la encargada de enviarlos ) tambiÈn est· encargada de decirle a esa clase a dÛnde los debe enviar. øQuÈ pasa si antes de enviar los datos hay que realizar alguna operaciÛn con ellos? ( por ejemplo, si son n˙meros, pasarlos a base dos, o cualquier otra cosa que se nos ocurra ). Pues que la clase intermedia har· esa operaciÛn antes de pasarle los datos a la clase encargada de enviarlos, a la cual, por cierto, la da igual lo que la pasen, simplemente, lo coge y lo envÌa.
Por tanto, hemos ganado en facilidad de mantenimiento, ya que sigue habiendo un cÛdigo com˙n para realizar las cosas entre todas las webs que tengan esta funcionalidad.
Pero adem·s, hemos dividido claramente la funcionalidad en pequeÒas piezas. De este modo, cuando haya un error en el envÌo de datos, sabemos que tenemos que empezar a buscarlo en la clase encargada de enviar los datos, y no en otra. A eso, lo llamamos modularidad.
Adem·s, ganamos en versatilidad, porque podemos hacer muchos cambios en la forma de actuar del programa sin cambiar cÛdigo ( por ejemplo, hacer que envÌe a un asp, en vez de a un php, etc.).
Igualmente, es mucho m·s f·cil aÒadir o aumentar las funcionalidades del programa, ya que, en el fondo, lo que estamos construyendo es una especia de puzzle, por lo que es como si sÛlo tuviÈramos que aÒadir m·s piezas. Aumenta la escalabilidad.
TambiÈn, hemos dicho que las clases ( esas entidades encargadas de realizar pequeÒas tareas ) ocultan los detalles de cÛmo realizan esas tareas, de modo que cualquier cambio en esa forma de realizar la tarea no afecta al resto del programa. Eso es el encapsulamiento.
Por tanto, aunque si utilizamos esta soluciÛn tengamos que escribir m·s cÛdigo para hacer lo mismo, a la larga, las ventajas son mayores que los inconvenientes. Sobre todo porque nuestros programas van a tener que adaptarse a unos requerimientos cambiantes ( nuevas peticiones del cliente, nuevas peticiones de nuestro jefe, etc. ), por lo que ser· mejor que nos pille preparados para que el mantenimiento sea lo menos traum·tico posible.
Gracias a Ignacio Caballero por la idea para este post.
