design-nation.blog/es

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.