Este tema no tiene nada de técnico, tan sólo voy a comentar cómo la aparición de Internet ha generado nuevos mercados que, a su vez, han generado nuevas formas de entender los negocios que precisan de tratamientos informáticos diferentes a los de “toda la vida”.

La “globalización” e Internet han hecho que cualquiera necesite ejecutar un “proceso” en cualquier momento, pero también en cualquier lugar, y alguien, con muy buen criterio, pensó que la forma normal de trabajar en programación no servía para este propósito. ¿Cómo podría yo aprovechar una función o un procedimiento hecho por otra persona desde el otro lado del mundo sin tener que conectarme a una red privada (virtual o no) para emular^[1] que estoy ahí? Porque hasta ese momento eso no era posible. Sí, podías llamar a un “programa” completo mediante una URL (siempre que tu plataforma y la del programa fueran la misma, por ejemplo un EXE en Windows), éste se descargaba a tu PC y se ejecutaba en local. Pero esa no era la idea. Así que se pensó en un sistema estándar que permitiese hacer lo mismo (o parecido) que hace RMI o CORBA en una red interna, pero en la red de redes, la web.

E inventaron los servicios web.

Un servicio web no es más que (definición de la Wikipedia) “una pieza de software que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones“. En lenguaje llano, un “programilla” (o un conjunto de funciones) que sirve para que cualquier otro programa pueda llamar a sus funciones para solicitar o enviar datos. Para ello se empleará XML^[2] como forma de codificar los datos, ya que, al ser texto plano, es perfectamente válido para ser pasado por HTTP.

Un ejemplo sencillo: tenemos una preciosa web que nos ofrece el tiempo en España. Creamos un servicio web que permita que cualquiera, desde otra web o programa (es indiferente) pueda llamar a ese servicio y obtener el tiempo de nuestra web, incluso de alguna provincia concreta mediante el paso de parámetros. Y todo esto teniendo acceso sólo a la web (es decir, puerto 80 u 8080, que todos los firewalls dejan libre para poder navegar por las páginas). ¿No suena bien?

A partir de ese momento, se nos abre un mundo de posibilidades: podemos crear un montón de servicios web que permitan a los demás consumir nuestros servicios, e incluso podemos consumir sus servicios también, en una forma de colaboración mutua, y todo esto solamente con tener acceso a Internet, nada más, olvidándonos de redes privadas, claves y demás.

Una vez que esto fue posible se abrió un nuevo mercado y nació la Arquitectura Orientada a Servicios (SOA), que básicamente es un negocio establecido en base a servicios web (aunque no es obligatorio que todo sean servicios web) donde se definen todos los servicios que ofreces para que los demás los puedan consumir. Los servicios que ofreces están descritos en el “catálogo” UDDI, de forma que cualquier servicio puede consultar ese catálogo y saber cuáles son esos servicios ofrecidos.

Una de las grandes ventajas de SOA es la posibilidad de “vender” un producto realizándolo “a medias” con otra empresa (o empresas) en la que cada uno realiza una función. Como quiera que el “usuario” (otro programador), al final, llamará a cierta función X que le devolverá lo que le interesa, a dicho usuario no le interesa quién desarrolló esa función, sino que funcione tal como la contrató. Otra ventaja es que las funciones las puedes programar en el lenguaje que prefieras, mientras las puedas instalar en el servidor aplicacional para que den correctamente su servicio. Además, al estar en tu servidor, las puedes cambiar, arreglar, mejorar… sin que el usuario se entere, mientras mantengas la misma forma de llamada. ¡Todo parecen ventajas!

Pues no, como siempre hay el lado malo: velocidad y dependencia, sobre todo.

Velocidad, porque el servicio no deja de estar en “Internet”, lo que conlleva pasar por muchos routers y servidores, y elevar consecuentemente los tiempos de respuesta (además de transformar todo a XML, con lo “verborreico” que es este estándar, y enviar un buen “churro” de caracteres). Y dependencia, en este caso, del acceso a internet y de tu proveedor del servicio: imagina que has contratado un servicio para tu web que te da las cotizaciones de la bolsa “on-line” porque tú ofreces servicios de broker y va, casualmente, y se cae el servidor donde tienes contratado el servicio web de donde leías esos datos. ¿Y ahora qué haces? Pues buscarte la vida si no tienes un plan B (cosa que en este país pasa mucho). Lo lógico sería tener previsto qué ocurre en caso de fallo y, dado que la base de tu negocio es el acceso a internet y al servicio web, tener duplicados los contratos, es decir, tener dos líneas de acceso a internet con proveedores distintos, y dos servicios web contratados en dos sitios distintos. Pero, claro, es que ”eso es el doble de caro“. Ya, ya, … así nos luce el pelo luego.

SaaS (Software as a Service)

Otra manera de ver los negocios que llegó con internet, y que a mí particularmente me resulta muy interesante, es ésta: el software vendido como un servicio, no como una propiedad. En la Wikipedia podéis encontrar información más detallada sobre esto, pero básicamente consiste en “alquilar” el software en vez de venderlo. ¿Cómo es eso, pago por algo que no es mío? Pues sí, y encima con bastantes ventajas. Sería como un renting de un coche, por ejemplo.^[3]

La empresa proveedora se encarga de tener siempre el software actualizado, disponible y listo para ser usado desde cualquier sitio (puede ser por internet o por VPN, por ejemplo) y el cliente se limita a pagar el alquiler del mismo. Cuando ya no le interesa usar más el servicio, deja el alquiler y listo. Un ejemplo de esto lo está intentando Microsoft desde la versión 2010 con el Office. Ofrecen un paquete en el que tú alquilas el Word, Excel, etc. para usarlo desde cualquier ordenador, pagando un alquiler por su uso. Si no te interesa esto, siempre puedes comprar una licencia “normal”, pero cuando salga Office 2011, con tu alquiler ya lo usarás desde el principio sin tener que cambiar nada en tu equipo, mientras que con la compra normal te quedarás en la versión 2010 salvo que vuelvas a pagar para actualizar.

Como véis hay muchas ventajas, pero dependerá de las necesidades de cada uno ver si es rentable o no. Lo mismo que el renting de un coche o el alquiler de un piso.

.

En general, la llegada de Internet ha cambiado las reglas de juego clásicas y ha abierto tantas puertas que es difícil abarcarlas todas. Antes (hablo de los 90) con saber C, Visual Basic o Cobol encontrabas trabajo seguro, pero ahora tienes tantas y tantas cosas, tantas tecnologías y lenguajes que te pierdes (yo, al menos, tengo nociones de algunas, oídas de otras y mucho uso de algunas muy concretas).

Yo creo que ha llegado el momento en las universidades de especializarse, como los médicos, cada uno en un campo: web, arquitecturas (cliente-servidor, distribuidas), SO (o bajo nivel), Bases de Datos (que esto también tiene tela ahora mismo, no hay más que intentar profundizar en Oracle mismamente y ya se ve), móviles y alguna más que no se me ocurre ahora. No tiene mucho sentido hoy en día sacar ingenieros técnicos “genéricos”, que saben poco de algunas cosas (porque, a pesar de las prácticas, el mundo empresarial es muy diferente) y mucho… de nada. Para ser competitivos hay que especializarse y ser el mejor en tu rama, para que los empresarios sepan dónde buscar.

Los tiempos de “soy informático, así que pregunta lo que quieras” se han terminado hace unos años. Lo mismo que un cirujano médico no le va a discutir a un traumatólogo en su campo porque no ha estudiado eso, no es su especialidad, los informáticos tenemos que tender a especializarnos en un área o dos como mucho, porque ya no hay tiempo que llegue para aprender de todo. Por regla general, los “inquietos” informáticos queremos saber de todo (ahora me quiero meter a aprender programación en Android o iPhone, pero me falta tiempo) y antes daba gusto porque casi podías llegar a hacerlo, pero… ya no. ¡Pardiez, que me voy por las ramas!

Me despido de vosotros (como escritor) porque ya no sé de qué más escribir en que tenga unos conocimientos más o menos asentados, así que espero que os haya gustado y… ¡hasta otra!

Enlace a la presentación de la serie.

1. Emular: Hacer creer al otro programa que en realidad soy otro o estoy en otro sitio.
2. XML: eXtended Markup Language. Es, a grandes rasgos, una forma de codificar la información de forma jerárquica, entre etiquetas de principio y de fin que indican dónde empieza y termina cada dato.
3. Nota del Editor: A pesar de su nombre tan moderno, esta práctica se viene haciendo desde siempre. Por ejemplo, todo el software básico de IBM para su serie “Z”, es decir, los mainframes, es alquilada, y hay otras compañías de software, como SAS, por ejemplo, cuya política, desde su fundación, no es vender licencias de software, sino alquilarlas… exactamente igual que SaaS propone. Sí, los mismos perros con diferentes collares. Solo que esta vez está disponible por internet y no tienen que “invadir” tu casa para actualizaciones, errores, etc., se hace todo en sus servidores.

Pero… ¿qué es eso de las capas? Definamos primero ese concepto para que se pueda entender todo mejor. Se habla de capas en la programación cuando queremos separar los componentes que permiten el funcionamiento de un programa en diferentes partes. Por ejemplo, cuando hablamos de dos capas habitualmente se refiere a la capa de presentación-negocio por un lado y a la de base de datos por el otro.

Vamos a partir del concepto actual de capas para que podáis entender mejor a qué me refiero. El modelo de tres capas, en el que hoy se basan casi todos los programas nuevos, consta de lo siguiente (extraído de la wikipedia):

1. Capa de presentación: es la que ve el usuario (también se la denomina “capa de usuario”). Presenta el sistema al usuario, le comunica la información y captura la información que proporciona el usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato y poco más). Esta capa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica, y debe tener la característica de ser “amigable” (entendible y fácil de usar) para el usuario.
2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos bien para almacenar, bien recuperar datos allí contenidos.
3. Capa de datos: es donde residen los datos, y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos y reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

En los albores de la informática (Mackuskey creo que os lo podrá confirmar), todo se hacía en una única capa (quizá no sea exactamente la expresión correcta, pero lo voy a expresar así). Digo esto porque el programador se encargaba de todo: imprimía los caracteres en pantalla, hacía los cálculos necesarios para cada proceso y, finalmente, grababa a mano los datos en los ficheros correspondientes, mejor dicho, emitía las órdenes de lectura o escritura exactas en los ficheros (no, no había bases de datos -en el resto del artículo, BDs- relacionales hasta los años 80), gestionando incluso los índices en algunos casos. Vamos, un auténtico “yo me lo guiso y yo me lo como todito”. ^[1]

Afortunadamente en los 80 llegó dBase (y Clipper más tarde), que ya eran sistemas gestores de bases de datos (aunque no usaban SQL) y permitían al programador usar sentencias parecidas a las actuales, tales como “carga/graba/borra este registro”. Quizá podríamos considerar ese momento como el paso a las dos capas, porque el programador ya no tenía que gestionar todo ”a mano”: por un lado tenía una BD, y por otro su capa negocio/interface. Ya en los 90 se popularizaron (porque hasta esa época era algo reservado al uso en los grandes ordenadores) las BDs relacionales. Y con esa popularización se empezaron a diseñar miles de programas usando la tecnología “cliente-servidor” (varios ordenadores con el mismo programa ”atacaban” una base de datos única). Y con esto llegamos al punto del tema en cuestión. No voy a ahondar demasiado en los conceptos porque, con una visita a la wikipedia, tenéis todas las definiciones que necesitéis sobre ello. Creo que con explicar lo básico se entiende la idea.

Así pues, yo definiría comunmente un sistema cliente-servidor como un sistema en el cuál tenemos una base de datos centralizada (la capa de datos) y un programa instalado en diferentes ordenadores que gestiona la capa de presentación y la de negocio a la vez (de ahí que se llame de dos capas). Por ejemplo, el clásico programa que emplean en un taller oficial de reparación de vehículos (supongo que habréis visto alguno al llevar el coche a la revisión). Estos suelen ser programas que acceden a los datos de la casa madre (eso, ahora que hay internet, porque antes era off-line y se cargaban los datos por la noche) y que el programa gestiona todo lo referente a los procesos y el interfaz de usuario (suelen estar hechos en Visual Basic, Delphi o similares). O también los programas que usan los cajeros de los bancos suelen ser así. Otro ejemplo serían las páginas web: los datos están en internet y el navegador sería el “programa” que visualiza y ejecuta (con javascript) las operaciones necesarias. Pero, por otro lado, también hay otro tipo de sistemas cliente-servidor en los que se mezclan la capa de datos y de negocio, y en la parte cliente tenemos la capa de presentación. De nuevo, una página web sirve como ejemplo, sólo que en este caso no usaría javascript para realizar los cálculos, sino que se harían en la propia BD (como, por ejemplo un procedimiento almacenado en la BD para realizar, digamos, la suma de las ventas de un mes).

En cambio, como se dijo anteriormente, un sistema de tres capas separa las dos que se juntan en el “cliente” de una forma que, en principio, trae numerosas ventajas, aunque veremos que luego no todo es tan bonito, como suele pasar siempre. La estructura habitual de instalación en un sistema de tres capas es: un servidor de bases de datos, un servidor de aplicaciones (capa de negocio) y una interface de usuario (capa de presentación), que suele ser tonta, es decir, se limita a trasladar las acciones del usuario en la pantalla a llamadas a la capa de negocio para que sea ahí donde se realicen los cálculos pertinentes. Esta arquitectura se puso de moda con la llegada de Java y sus aplicaciones multiplataforma.

Ahora llega la parte práctica del asunto: ¿y cuál me interesa a mi usar? Pues para saber eso hay que conocer los puntos fuertes y débiles de cada tecnología, así que veámoslos primero.

Cliente-servidor: ventajas e inconvenientes

(Capa de negocio en el cliente, también llamado cliente rico o pesado)

Como tecnología bien conocida, por el tiempo que lleva en producción, es ampliamente usada. Lo cierto es que para la mayoría de aplicaciones comunes es más que suficiente, pero empieza a cojear cuando se tienen muchos clientes atacando al servidor (y se espera una respuesta rápida, lógicamente). Las mayores ventajas son:

1. Aplicaciones cliente ricas en contenido y rápidas: el hecho de tener todo, menos los datos, en la propia aplicación hace que, disponiendo de un puesto cliente con el hardware adecuado, todo en la aplicación fluya con rapidez (siempre que los datos estén disponibles). Las operaciones que se realizan sobre los datos son instantáneas (no hay que esperar a que lo haga otro servidor y esperar su respuesta). Por ejemplo, si recordáis al principio de internet cuando las páginas web tenían, digamos, un desplegable de provincias y ciudades (donde las ciudades dependen del contenido de la provincia), cuando pinchabas una provincia, la página web llamaba al servidor, éste obtenía las ciudades relacionadas con la provincia y devolvía la página nuevamente para seleccionar la ciudad. Esto era, obviamente, hiperlento. La otra posibilidad era tener un código javascript (capa de negocio) que ya tuviese todos los valores de provincias y ciudades grabadas y, en ese caso, todo era instantáneo. A cambio, la página era mucho más pesada de cargar (cliente rico o pesado). La velocidad de ejecución del javascript dependía en este caso de la potencia del cliente.
2. Actualizaciones independientes: diferentes clientes pueden tener versiones diferentes de la aplicación a la vez funcionando, lo cual sirve, por ejemplo, para actualizar sólo una parte de todos tus clientes, a modo de conejillos de indias, y ver si lo nuevo realmente funciona en real.
3. Fácil escalabilidad en los clientes: es muy fácil añadir nuevos clientes, ya que sólo van a necesitar una conexión para obtener los datos, lo cual no incrementa en mucho las necesidades del servidor. Ahora bien, si la aplicación precisa continuamente de datos del servidor, lógicamente éste se verá sobrecargado muy rápidamente conforme crece el número de clientes.
4. Servidor normal: ya que sólo se va a encargar de los datos, aún siendo estos muy importantes, no es preciso un súper-servidor para tener esos datos disponibles. La CPU apenas va a estar ocupada, sólo va a ser necesaria para el gestor de la BD. Eso sí, el sistema de discos es aquí crítico.

Como inconvenientes yo citaría los siguientes:

1. Los clientes deben tener ciertos requisitos de hardware: evidentemente, el hecho de que los cálculos se realicen siempre en el cliente obliga a que el hardware pueda llevarlos a cabo con solvencia. Todos recordaréis los “requisitos mínimos” que suelen pedir los programas para instalarse.
2. Instalaciones de los clientes engorrosas: hay que ir cliente a cliente instalando la aplicación, al menos la primera vez, ya que suele traer muchos ficheros de los que depende (baste ver una clásica instalación de Visual Basic para darse cuenta). Las famosas DLLs de las que dependen muchos programas son parte causante de esto. Una vez hecho esto, y si no se añaden nuevas dependencias al programa, las actualizaciones son más fáciles (habitualmente, copiar un único archivo).
3. Red de la empresa congestionada: suele haber mucha información, sobre todo resultados de consultas SQL, fluyendo por la red, desde el servidor a cada cliente y viceversa. Esto no es así (en realidad depende) con las tres capas, ya que ahí solo fluyen los resultados a mostrar en pantalla, mientras que en tecnología cliente-servidor cada cálculo necesita de unos datos que son pedidos y llevados al cliente, para efectuar sus operaciones (muchas veces son muchos datos, como por ejemplo, obtener la lista del todos los clientes o productos, y hacer operaciones con ellos). El hecho de que las operaciones se realicen en el cliente implica que si para obtener, por ejemplo, el resultado de compras+ventas-devoluciones necesito obtener esos datos cada vez y calcularlos en el cliente, las tres informaciones van hasta el cliente, realiza la operación y envía el resultado para ser grabado. Si estas mismas operaciones se hacen en el servidor, nada viaja por la red, salvo el resultado.

Cliente-servidor: ventajas e inconvenientes

(Capa de negocio en el servidor, también llamado cliente ligero)

Aquí la parte de negocio se mezcla con la de acceso a los datos para obtener una respuesta que luego será enviada al cliente (y éste la mostrará en pantalla, esperando una acción por parte del usuario). Ésta es, a mi entender, una mala filosofía de programación, puesto que mucha parte del negocio se encuentra en la propia BD en forma de procedimientos almacenados o triggers, lo que hace totalmente dependiente el producto software resultante de la BD en la que se desarrolle. Suele ser, además, un compromiso mixto, ya que otra parte pequeña del negocio se debe situar en el cliente casi siempre (los lenguajes de BD suelen ser limitados) y, entre los dos, consiguen llevar a cabo sus acciones. En este caso las ventajas son:

1. Rendimiento del sistema: normalmente, la misma operación realizada en el cliente o en el servidor (atendiendo a cálculos con datos) se ejecuta mucho más rápido en el servidor, dado que las propias BDs tienen los procedimientos compilados y, además, es posible que si una operación es muy solicitada permanezca en la caché del sistema, siendo aún más rápida.
2. Actualizaciones automáticas: cualquier cosa cambiada en el servidor (a nivel de negocio o datos) repercute automáticamente en el cliente sin tener que hacer nada. El paraíso para los administradores de sistemas.
3. Requerimientos de ordenador casi inexistentes: dado que el cliente no hace más que visualizar cosas, apenas hay requerimientos hardware.
4. Instalaciones/actualizaciones sencillas: incluso inexistentes, si estamos hablando de páginas web.
5. Red de la empresa menos sobrecargada: todas las operaciones se realizan en el servidor, al cliente solo se le envía lo que tiene que ver.

Como inconvenientes yo citaría los siguientes:

1. La instalación de los clientes debe estar controlada: dada su facilidad de expansión, meter muchos clientes sin tener dimensionado el servidor para ese número ralentizará el sistema, llegando incluso a colapsarlo.
2. Actualizaciones cuidadosas en el servidor: hay que tener mucho cuidado con las actualizaciones, ya que todos los clientes cambiarán simultáneamente de comportamiento y, en caso de error, ninguno funcionará correctamente. Lo normal en un programa es que la parte más cambiante esté en la capa de negocio y, al estar ésta en el servidor, será habitual que haya actualizaciones, lo cual es siempre un punto crítico en cualquier sistema.
3. Servidor muy potente: Será el servidor quién se encargue de todos los procesos (y también de los datos, habitualmente), por tanto debe ser lo suficientemente potente como para soportar todas las peticiones y procesos que le sean requeridos.
4. El más importante bajo mi punto de vista, imposibilidad de cambio de motor de BD: una vez que se empieza a trabajar con el lenguaje de programación específico de una BD y que el programa crece y crece (para variar), el día que se decida cambiar de BD (por ejemplo, migrar de SQL Server a Oracle para ganar en rendimiento) será absolutamente imposible sin reescribir toda la capa de negocio de nuevo. Ya sólo por este motivo yo soy partidario de elegir un cliente-servidor pesado.

3 capas: ventajas e inconvenientes

Y llegamos al modelo de moda. Es un modelo que, técnicamente, parece perfecto. Además, sobre el papel debería funcionar mejor que nada… aunque la experiencia me dice que no siempre es así.

Tal como vimos al principio, en un modelo de 3 capas tenemos todo separado, lo cual nos proporciona muchísimas ventajas y apenas incovenientes. Veamos ambos.

Ventajas:

1. Aplicaciones cliente ligeras: ya vimos algunas de sus ventajas en los clientes ligeros, a saber: actualizaciones automáticas (siempre que no sean de la interfaz), requerimientos mínimos del cliente, instalaciones sencillas, red poco cargada. El programador en este caso tan sólo debe preocuparse del aspecto gráfico de la misma y de llamar/recibir a los eventos que el usuario puede disparar.
2. Modelo de procesos independiente: si algo está mal, si queremos añadir funcionalidades, nuevos cálculos, … cualquier cosa que el programador quiera hacer la puede hacer y actualizar sin interferir apenas con los usuarios o con la BD. Una vez que todo esté correcto bastará subir los cambios a un único sitio y, como por arte de magia, todos los clientes disfrutarán de un nuevo programa.
3. Alta escalabilidad del sistema: esto, que se dice mucho y se entiende poco al principio, significa que podemos agregar/quitar al sistema tantos clientes y servidores como necesitemos si el volumen de trabajo crece o decrece. Por ejemplo, imaginemos que teníamos un único servidor de aplicaciones que da soporte a 10 clientes simultaneos pero de repente entran 10 más por picos de trabajo puntuales. Si el sistema se resiente, como es previsible, bastará con añadir un segundo servidor de aplicaciones (capa 2, la de negocios) y un balanceador de carga para que las peticiones de los clientes se repartan automáticamente entre los dos servidores de aplicaciones. Los clientes también crecen pero el servidor de datos se mantiene (si estuviésemos en el caso de cliente (ligero)-servidor sólo cabría aumentar la RAM del servidor, mejorar el procesador (raro-raro) y rezar para que con eso fuese suficiente. En caso de no serlo… tocaría cambiar de servidor).
4. Fácil mantenimiento: al estar todo separado, cualquier operación es más sencilla de realizar dada la especificidad de las funciones en cada capa. Vamos, que si empieza a fallar, digamos, el servidor de aplicaciones, se prepara otro enseguida y se puede cambiar en “ná-y-menos”.
5. Alta tolerancia a fallos: es fácil construir un sistema 24/7^[2] de alta disponibilidad, basta redundar (duplicar) cada capa y meter un sistema balanceador de cargas que detecte cuándo se cae un servidor para pasar las peticiones al otro. Cuando un sistema se monta así, estamos hablando de un clúster con diversos nodos.
6. Bases de datos como simple almacén: no ejercen más labor que la de almacén de datos, lo que posibilita la migración en caso de ser necesario, tanto entre versiones de la misma BD como entre diferentes motores de BD.

Inconvenientes:

1. Red de la empresa más cargada: esta desventaja es relativa, puesto que sólo ocurre cuando la instalación de la capa de aplicaciones está separada de la de la capa de datos (sí, es posible perfectamente instalar en el mismo servidor físico la capa de negocio y de datos, pero se pierde alguna ventaja como la tolerancia a fallos, por ejemplo). Si es así, las peticiones van desde el cliente a la capa de negocio, y desde la capa de negocio a la BD (y el camino opuesto), moviendo más información por la red que si tuviésemos una aplicación cliente-servidor.
2. Programación más compleja: el hecho de que tu programa dependa de varios servidores hace que sea un poco más complicado tanto el desarrollo como los test. Más piezas en la ecuación, más posibles puntos de fallo. No hablemos ya de la detección/corrección de errores…
3. Servidores especializados, y más caros por tanto. Todo depende, como siempre, de cuánta seguridad quieras, pero si se quiere cierta tolerancia a fallos hay que tener al menos dos servidores y algo que los sincronice. Además, ya estamos hablando de un servidor aplicacional y otro para BD, lo cual requiere de mayores conocimientos (tanto en su gestión como en la programación) que para un clásico programa cliente-servidor.
4. En general, respuesta más lenta en los clientes: y éste es el punto por el que yo no siempre elegiría este modelo. Todo es muy bonito en el papel, pero, como resultado de todo este entramado, lo que obtenemos son peticiones a servidores de aplicaciones y respuestas de estos. Por muy rápido que sea el proceso, siempre va a tener que ir y volver, como mínimo, y aunque para la web los servidores aplicacionales son muy rápidos (porque es la velocidad de la conexión la que acaba determinando la velocidad), para un cliente una espera de un segundo puede ser todo un mundo, dependiendo de lo que necesite.

Entonces, ¿cuál es mejor?

Pues como casi todo en la informática, eso va a depender de varios factores, eso sí, algunos de ellos totalmente determinantes. Por ejemplo, ¿necesito un sistema muy escalable? Pues amigo, ni te lo pienses, como las 3 capas no encontrarás uno mejor. ¿Sistema 24/7 de alta disponibilidad? Bien, en realidad esto también lo tienes con cliente-servidor en sus “dos modalidades”: basta redundar el SGBD de forma que si cae un servidor se active el otro (todo de forma transparente para el cliente). Quitando ciertos factores determinantes, como la escalabilidad, si lo único que es fundamental es la experiencia del usuario (cliente) yo me inclinaría por un sistema cliente(pesado)-servidor, donde los procesos se ejecutan casi al instante, y os voy a comentar un caso real (conozco más, pero con uno llega) que ocurre actualmente para apoyar esta afirmación.

Uno de mis conocidos tiene una empresa en la que tenía su sistema de gestión de toda la vida, una BD Informix que era atacada por un programa realizado en Multibase. No es que no estuviesen contentos con el sistema, que sí lo estaban, pues hacía lo que tenía que hacer y lo hacía bien. Pero llegó una empresa consultora de esas que tanto abundan hoy que convenció al gerente (mi amigo) de que 15 años con el mismo programa era de dinosaurios, que había que actualizar los equipos porque si fallaba alguno luego a ver quién le montaba un servidor nuevo con esa versión de Informix, que si esto, que si lo otro… vamos, la cantata de siempre de “actualícese, so dinosaurio, que todos tenemos que comer“. El caso es que este hombre aceptó, incauto de él, pensando, como Don Hilarión, que “la ciencia avanza que es una barbaridad” y que a peor no podría ir: ¡¡un sistema con 15 años tiene que ser mucho más lento que uno de hoy en día, vamos hombre!!

Total, pasamos de un sistema cliente-servidor (donde los usuarios pulsaban intro para llegar a la casilla donde querían ir, al viejo estilo DOS) a un flamante sistema de 3 capas con su servidor de BD IBM con Oracle 10g, otro servidor aplicacional con Tomcat 5.5 y un bonito programa hecho en flash con la tecnología FlashRemoting (es como un programa normal de flash que se ejecuta como un EXE cualquiera en vez de en un navegador web, de hecho es un EXE). La verdad es que lo vi y era precioso, con sus botones redondos y sus animaciones tan bonitas… era precioso, digo, hasta que lo vi funcionando. No estaba nada mal, ojo, más o menos hacía las cosas bien, tenía ciertas ventajas, cosas mejoradas respecto a lo que tenían antes (si no, apaga y vámonos), etc, pero era… LENTO. O sea, LENTO. No es que la pantalla fuese lenta al teclear, ni cosas así, lo que era lento es la transición entre pantallas: entrabas en un cliente y tardaba 2 segundos en mostrar los datos, desde ahí accedías a sus pedidos y tardaba otros 2 segundos en mostrarlos (siempre aparecía un relojito indicando la “petición” de los datos al servidor), y así, de pantalla en pantalla, a razón de 2 segundos (o más, pero nunca menos).

Dos segundos pueden parecer una tontería, pero cuando el usuario estaba acostumbrado a pulsar intro y que en medio segundo apareciesen los datos, hacer intro 3 veces más (ya de memoria) para llegar a donde quería, escribir lo que procediese y pulsar intro para grabar y llegar al pedido, y todo esto en menos de 3 segundos, y ahora este mismo proceso le cuesta 2s + ratón a la casilla de destino y escribir el valor (X segundos) + 2s, y esto repetido en el día docenas o centenares de veces, pues… mal vamos.  El usuario final se enfada, la empresa pierde rendimiento del trabajador y, encima, le ha costado dinero (y más que le costará, y si no, al tiempo). Mi amigo ahora desconfía de las consultoras (como es lógico), y está con un cabreo de tres pares (como es lógico, también).

Con esto quiero dar a entender que las tecnologías no deben adoptarse porque sí, deben adoptarse porque mejoran lo que hay, si no, es un sinsentido. Realmente las 3 capas traen muchas ventajas, sobre todo para los administradores de sistemas, pero hay que pensar bien dónde se aplican, ya que la velocidad de la aplicación no es tan buena como la de un cliente-servidor. Por ejemplo, ahora es muy típico que en la Administración (o sea, el Gobierno central, autonómico, municipal y demás) te pidan que todas las aplicaciones que tú les vendas tengan una arquitectura de 3 capas. Es más, si no es así ya no entras siquiera a concurso. Imponen la tecnología a emplear. Luego salen churros infumables (no todos, lógicamente) y no siempre la empresa es la culpable, es que la han obligado a hacer las cosas con una tecnología inadecuada para el propósito buscado.

En fin, espero que os haya gustado este artículo. Todo lo que aquí digo no es más que mi propio conocimiento basado en mi experiencia de estos años. Puedo haberme equivocado en algo, en cuyo caso no dudéis en decírmelo y, si es menester, corregiré el artículo para que sea lo más correcto y lo menos técnico posible.

El último artículo de mi lista es Servicios web (WS), Arquitectura orientada a servicios (SOA) y demás zarandajas de la “globalización” de los programas. Ahí os espero.

1. Nota de Macluskey, por alusiones: Confirmo que era así, sin duda. Hasta los años 70 no existían bases de datos de ningún tipo, y hasta mediados, más bien fines, de los 80, no existieron las primeras bases de datos relacionales. La primera de ellas operativa fue SQL/DS, de IBM para VSE, seguida al poco por DB2 para MVS, ambas en ambiente mainframe de IBM, lo que tras varios cambios de nombre ahora se llama z/OS
2. 24/7 indica disponibilidad de 24 horas al día y 7 días a la semana

La Programación Orientada a Objetos (POO)

¡No veáis qué cambio supone esto con respecto a la PP! El concepto es totalmente diferente y, viniendo de la PP, cuesta cambiar esa mentalidad (se hace más fácil para alguien que no ha visto esto nunca).

Primeramente, la definición formal (me vale la de la Wikipedia): “La programación orientada a objetos o POO es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas de ordenador. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento“. Toma del frasco, Carrasco. ¿Alguien ha entendido algo, así, a bote pronto?

Si en la PP únicamente teníamos que pensar en qué funciones queríamos realizar y codificarlas, para poder llamarlas luego desde cualquier parte del programa, ahora la cosa es como sigue: tienes un mundo real, así que lo que vayas a programar debería encajar lo mejor posible con ese mundo. En el mundo hay cosas, objetos, y sobre ellos haces operaciones. Por lo tanto, cuando diseñes el programa, no pienses en qué debe hacer esta operación o aquella otra, piensa que un objeto debe transformarse mediante sus operaciones y de él podrás extraer un resultado o usarlo para otros menesteres.

Esto, visto así de forma abstracta, parece que se entiende, pero luego, a la hora de ponerlo en práctica, no es tan fácil. Veamos un ejemplo sencillo:

Tengo un coche, que está formado por 3 partes: ruedas, motor y chasis. El programa que necesitas debe comprar piezas para tener coches y venderlos. Bien, en un programa estilo PP podrías hacer esto (lo que pongo es pseudocódigo, una descripción natural de lo que haría el programa, no código fuente):

Variable coche1;
Variable ListaPiezas;

Procedimiento ComprarPieza(tipo de pieza);
Procedimiento MontarPiezas(lista de piezas);
Procedimiento VenderCoche(coche);

Función Principal (
  ComprarPieza(rueda);
  ComprarPieza(rueda);
  ComprarPieza(rueda);
  ComprarPieza(rueda);
  ComprarPieza(motor);
  ComprarPieza(chasis);
  MontarPiezas(ListaPiezas);

  VenderCoche(coche1);
)

Esto, con POO, no es tan fácil como lo que aparece ahí arriba. Primero, debemos definir una “entidad” (el objeto) genérica de la que se puedan “extraer” variables que sí podemos usar, es decir, debe existir un objeto genérico coche del que sacaremos, cada vez que lo necesitemos, las variables coche1, coche2, etc. que será con las que podemos tratar para añadirles piezas y venderlos. Ese objeto coche debe tener sus propias funciones (se llaman métodos) con las que operar, porque si no, no podremos hacer nada con él. Y esto es así porque, por definición, los objetos son cerrados y nada puede acceder a sus propiedades o funciones, salvo que nosotros queramos que así sea (definiéndolos de esa forma, como públicos). Esto se hizo así en parte para evitar que los malos programadores abusasen de las variables globales y que otras funciones pudiesen tocar los valores del objeto. De esa forma, si mi objeto es sólo mío, sólo yo puedo manipular los valores de mis variables, así que siempre las tendré controladas y no habrá la posibilidad de que un error en una llamada a una función con el mismo nombre que la mía me cambie el objeto sin darme cuenta.

Por lo tanto, debemos definir el objeto y las funciones posibles del mismo (no lo voy a complicar en demasía, sólo para hacerse una idea). Podría quedar algo así:

Definición de Objeto Coche;
  Variable Privada rueda (es un tipo de pieza);
  Variable Privada motor (es un tipo de pieza);
  Variable Privada chasis (es un tipo de pieza);

  Procedimiento Público ComprarPieza(tipo de pieza);
  Procedimiento Público MontarPiezas();
  Procedimiento Público Vender();
Fin de la definición;

Mis variables:
Variable coche1 de tipo coche;

Función Principal (
  coche1.ComprarPieza(rueda);
  coche1.ComprarPieza(rueda);
  coche1.ComprarPieza(rueda);
  coche1.ComprarPieza(rueda);
  coche1.ComprarPieza(motor);
  coche1.ComprarPieza(chasis);
  coche1.MontarPiezas();
  coche1.Vender();
)

Bien, parece fácil a priori… Sí, bueno, la teoría es sencilla hasta que te enfrentas a un programa real con multitud de objetos que tienen que interactuar entre sí. Entonces te das cuenta de que, de serie, todo es privado, así que aquello que era tan fácil, como llamar a una función para hacer una serie de cálculos sin mayor importancia, ahora se transforma en una mezcla de objetos que tienen que tener bien “configuradas” sus variables y funciones para ser accesibles desde otros objetos. Luego tienes el añadido de que si trabajas, por ejemplo, con Java, es tan estricto en sus definiciones que a la mínima te da un error de “incongruencia” cuando intentas llamar a una función o usar una variable que es de otro tipo (no es que esto sea malo, sólo que es muy exigente, a veces demasiado). Encima, si quieres realizar alguna función “general” para todo el programa, algo tan simple como “Sumar(numero 1, numero2)”, no hay una “sección” donde puedas colocar funciones generales globales, aquí todo son objetos y deben estar dentro de un objeto, por lo que toca crear un objeto “FuncionesGenerales“, y dentro definir las funciones que quieras. Esto no casa con eso de “objetos reales del mundo” del que hablaba este modelo, pero para ser coherentes con el mismo, debe ser así.

Bueno, en el ejemplo se ve bonito y hasta fácil de entender, pero como digo, eso es lo que parece cuando sólo tienes un objeto. Y además, esto es sólo lo básico, aún falta ver la otra parte de la definición: “… herencia, abstracción, polimorfismo y encapsulamiento” decía, ¿no? Aquí es donde se lía todo.

Herencia, abstracción, polimorfismo y encapsulamiento… ¿ein?

¿Pero… esto qué es lo que es? Con lo feliz que era yo con mis variables y mis funciones… pero chico, las cosas evolucionan. Realmente esto es lo que le da la potencia real a los objetos, lo anterior es tan sólo una organización más estricta de los datos y funciones. Os recuerdo que, para no liar al personal, seguiré hablando de funciones (para los métodos) y variables (para los atributos):

Herencia

Pues es una propiedad por la que un objeto “hijo” hereda de su “padre” todas sus funciones y variables, de forma que no tenga que volver a codificarlas. Ejemplo: teníamos un coche, ¿verdad? Le tuve que decir al coche que tenía chasis, motor y ruedas. Si ahora vendo también motos, tendré que volver a definir todas las piezas de la moto, que al fin y al cabo son las mismas (pero solo hacen falta 2 ruedas). ¿Qué tal si en vez de definir un objeto coche y otro moto, defino uno más genérico (el padre) llamado vehículo? Si sus hijos heredan sus propiedades, ya no tendré que definir dos veces lo mismo, me vale con decir que coche y moto son vehículos. Esto sería algo tal que así:

Definición de Objeto vehículo;
  Variable Privada rueda (es un tipo de pieza);
  Variable Privada motor (es un tipo de pieza);
  Variable Privada chasis (es un tipo de pieza);

  Procedimiento Público ComprarPieza(tipo de pieza);
  Procedimiento Público MontarPiezas();
  Procedimiento Público Vender();
Fin de la definición;

Mis variables:
Variable coche1 de tipo vehículo;
Variable moto1 de tipo vehículo;

motoHonda4cil600ccDobleFaro.ComprarPieza(motor4cil600cc)

Y dices tu: vaya, esto me suena a algo. Y empiezas a investigar. Primero miras qué funciones tiene motoHonda4cil600ccDobleFaro y te das cuenta de que tiene 1 ó 2, pero no es ésa. Pero ves que este objeto es hijo de motoHonda4cil600cc. Vas a buscar a ese objeto a ver si está allí la función y… tampoco, pero ves que es hijo de motoHonda4cil y crees que estará allí. Vaya, tampoco, pero es hijo de motoHonda y crees que ahora sí que sí. Error, éste es hijo de vehículo. ¡Vaya, por fin veo la función original, ya puedo seguir el flujo del programa! Afortunadamente, los entornos de programación actuales buscan la función por ti y siguen ese flujo, pero si ves el programa en papel es para llorar… Igual te preguntas por qué salieron tantos hijos. Sencillo: el programador quería heredar todas las características de cada uno de los padres, ya que cada padre agregaba una característica única al objeto final. Hay motos, algunas son marca Honda, algunas son de 2 cilindros y otras de 4, la cilindrada es variable (600 en este caso) y además, el chasis puede ser de doble faro o simple. ¿Alguna duda?

Abstracción

Que palabra más fea, pero, en resumen, viene a decir que tú puedes usar las funciones de los objetos sin necesidad de que sepas qué hacen o cómo lo hacen. Si total, para qué lo quieres saber, con tal de que hagan lo que prometen (no como los políticos). Esto ayuda a que no te entrometas en sus funciones y así no puedas modificar su comportamiento. Por ejemplo, a tí te basta con saber que coche1.MontarPiezas(); hace que el coche se monte con las piezas que compraste. Te da igual cómo lo haga, con tal que lo haga bien. Esa función posiblemente calcule si tiene las piezas necesarias y realice el montaje, pero en realidad a ti todo eso te da igual.

Polimorfismo

Si la palabra de antes era fea, ésta mete miedo y todo. Y sin embargo es muy útil y fácil de comprender. Lo que significa es que puedes tener la misma función con el mismo nombre en objetos hijos, pero que internamente hacen cosas diferentes a la misma función que hay en el padre. Con el ejemplo se ve claro: resulta que tienes tres formas (o más) de montar un coche, por ejemplo un cocheNormal (un vehículo), un cocheHondaCupe y un cocheHonda5Puertas. Pero tú lo que quieres es que todo el mundo use el mismo método de montar las piezas, de forma que el proceso sea siempre el mismo (es decir, que obtengas el coche montado y listo para su venta), eso sí, sólo cambia la forma de hacerlo. Con PP tendrías que definir tres funciones, ya que no podrían llamarse igual: MontarPiezas, MontarPiezasCupe y MontarPiezas5Puertas. O bien, si más del 50% del código es igual, hacer una función con un parámetro que indicase la forma de montaje: MontarPiezas(Puertas) y, según eso, en el código hacer una cosa u otra.

Pero llega el polimorfismo para arreglar esto de tener tres funciones diferentes (ya digo, si el código es igual en más de un 50% no merece la pena, lo arreglas con una variable que decida qué hacer). Como quieres que siempre se use la función MontarPiezas, pues defines en cada uno de los hijos de un objeto vehículo la función MontarPiezas, solo que el código de cada función será diferente y realizará las operaciones que necesite para obtener el coche montado:

Variable cocheNormal de tipo vehículo;

Variable cocheHondaCupe de tipo vehículo;
  Procedimiento Privado MontarPiezas() {
    Acciones abc...
  };

Variable cocheHonda5Puertas de tipo vehiculo;
  Procedimiento Privado MontarPiezas() {
    Acciones xyz...
  };

código para montar un coche normal...;
cocheNormal.MontarPiezas();
código para montar un coche cupe...
cocheHondaCupe.MontarPiezas();
código para montar un coche de 5 puertas
cocheHonda5Puertas.MontarPiezas();

Encapsulamiento

Bonito palabro, suena futurista y todo, pero simplemente quiere decir que unes todo lo referente a un objeto dentro de él, es decir, no deberías necesitar, para trabajar con ese objeto, nada externo. Como vimos con el coche, en la PP todo era libre y cualquiera podía hurgar en él. De hecho, el pobre coche1 no tenía forma de evitar que nadie tocase cosas de él, era un simple títere. En la POO tenemos todas las variables y funciones dentro del objeto coche. Es, como si dijéramos, autosuficiente.

Conclusiones

No voy a ahondar más en este tema, porque hay abundante literatura de él. Tan sólo trato de dar una vista general del mismo. Como todo en esta vida, hay que buscar el compromiso adecuado entre organización y comprensión. Ni la PP ni la POO son siempre lo mejor, depende del caso que trates y de tus conocimientos.

Yo, por ejemplo, prefiero la PP porque:

1. Suelo hacer programas pequeños y simples.
2. Es más rápido.
3. Es más fácil de mantener.
4. Sólo los hago yo.

Sin embargo, entiendo que para ciertas tareas es mejor usar POO. Por ejemplo, si más de una persona va a trabajar en el proyecto, o si hay varios proyectos abiertos y muchas partes son comunes: puedes aprovechar tus objetos ya definidos para el otro programa. Un ejemplo sería, tengo un programa de gestión de almacén de vehículos y otro de venta: si defino el objeto vehículo en uno, es posible que tenga muchas cosas en común con el otro programa, y por tanto mucho código que tenga escrito de uno me valdrá para el otro. Esto lo facilita el encapsulamiento, ya que se supone que el objeto es “autosuficiente”.

Podemos decir también que la PP facilita una programación más “libre” o más “sobre la marcha”: es ideal para los improvisadores. Si en un momento determinado se te ocurre una novedad a incorporar, la flexibilidad que tiene permite meterla en “ná y menos“. La POO es lo contrario, deberías haber analizado bien el problema antes, reconocido y separado sus objetos, para luego definirlos y empezar a operar con ellos. Agregar una función nueva a un objeto es sencillo si la operación es “interna”, pero interactuar entre objetos ya no es tan sencillo si no lo habías planificado.

La ventaja de libertad de la PP es también su mayor problema: hay miles de desastrosos programas que han dado la mala fama a los lenguajes que emplean esta metodología (como Visual Basic). Sólo hay que buscar programas de ejemplo, y en más del 50% de los realizados con VB se podrán apreciar varias faltas (no obligatoriedad de declarar variables, código spaguetti, funciones sin ton ni son, etc.) Y, derivado de esto, viene la “fama” de que los que usan POO son unos fieras porque para eso “hay que saber”, en cambio para usar PP hasta el vecino puede… pero para usarla bien hay que ser más fiera que los de la POO, porque para eso necesitas buenos conocimientos, disciplina y orden (en la POO se te obliga a hacer las cosas, con lo que si no eres disciplinado, la metodología lo es por tí).

Por poner un ejemplo real, yo digo que suelo hacer programas pequeños, pero con VB tengo realizados (y en producción) tres programas empresariales de gestión (uno para un almacén de ropa, otro para gestión de lotes avícolas y otro para una academia a nivel autonómico), con más de 20.000 líneas de código y que llevan más de 10 años funcionando cada uno sin la menor incidencia, más allá de las típicas “nuevas funcionalidades” que demandan los clientes. Trabajan con ellos más de 20 usuarios simultaneos. Ya véis, PP con Visual Basic, ni un objeto, y funcionando sin problemas, con fácil mantenimiento y relativamente fácil ampliación de funcionalidades. Es decir, la POO no es la panacea, es sólo… otra metodología.

¿Cuál interesa más? Pues como dice “Jarabe de Palo” en su canción… ¡depende!

Bueno, finalmente comentar que he tratado de que el tema se haga de la forma más abstracta y alejada de tecnicismos posible para entender las bases. No se pretende explicar en profundidad cada metodología, para eso imagino que hay miles de páginas centradas en cada cosa. Esto pretende ser solo una orientación de “por donde van los tiros”. No sé si lo he conseguido, pero es la intención. Espero que os haya gustado este breve VS. Ahora toca empezar con el próximo combate: Sistemas cliente-servidor vs Sistemas multi-capa

Os pongo en antecedentes para que os podáis situar bajo mi punto de vista:

Aprendí a programar yo solo con mi primer ordenador, unToshiba MSX-HX10 como el de la imagen de al lado, con sistema operativo BASIC. Esto debió ser a los 10 años, que fue cuando me lo pude comprar con los ahorros (los míos y los de mi hermana, le dije que así podíamos jugar también y coló, que tampoco fue mentira porque jugamos un montón).

En aquel momento triunfaban los concursos de preguntas y respuestas en la tele, así que decidí hacer uno en el ordenador. En total eran 25 preguntas y una chapuza de INPUTS e IF anidados… que funcionaba.

Desde entonces hasta ahora, la PP siempre me ha acompañado fielmente. En la carrera, la POO todavía era algo “novedoso” y sin mucha implantación aún, así que nos enseñaron PP y toda la teoría y las prácticas eran así: Pascal, C, Cobol y todos los lenguajes anecdóticos de la época (como Fortran o la Lista Interminable de Soporíferos Paréntesis, más conocida como LISP^[1] ).

Ni siquiera nos enseñaron Visual Basic, que ya por entonces era el lenguaje más popular de todos, al que más cariño le tengo (los puristas me crucificarán por esto, pero qué se le va a hacer) y con el que me he sacado las castañas del fuego durante 15 años ya, aunque ahora apenas lo toque (sniff).

Mi primer contacto real (la teoría es muy bonita, pero si no la llevas a la práctica…) con la POO fue con Java en el año 2004, cuando por temas de mi trabajo precisaba una aplicación de consola que corriese en Linux o Windows y atacase a una base de datos Informix por un lado y Oracle por otro. Ahí fue cuando descubrí lo complejo que es cambiar de mentalidad para pasar de PP a POO (y viceversa). Y ahora sí, podemos entrar en temática.

La Programación Procedural (PP)

Antes de nada, debo aclarar que a veces se puede uno referir también a la programación funcional y meterlo todo en el mismo saco, pero éste no es el término exacto de lo que voy a definir, ya que la programación estrictamente funcional está basada únicamente en funciones (no procedimientos). Según la Wikipedia, “La programación funcional es un paradigma de programación declarativa basado en la utilización de funciones matemáticas“.

Con esta definición, lenguajes como Visual Basic o C no entrarían ahí. Por eso aclaro que a veces se habla de la Programación Funcional queriendo incluir la Programación Procedural (PP) o, también llamada Programación Estructurada. Por ello, para resumir y no decir tantas palabras feas, cuando hable de PP en general me quiero referir tanto a PF como a PP, ya que al final todo son funciones o procedimientos colocados de una forma estructurada y coherente que dan vida a un programa.

Dicho esto, ¿qué es la PP (o, recordemos, estructurada)? Bueno, veamos la definición de la wikipedia: “La programación estructurada es una forma de escribir programas de ordenador de manera clara.” Y tan clara, añado yo… siempre que el programador tenga claro el concepto. He llegado a ver auténticos churros de código, sin sentido aparente, de recién licenciados en la carrera (lo cuál no decía nada bueno de ellos, porque una cosa es la inexperiencia y otra “el churro”).

Bien, básicamente lo único que se necesita para usar esta técnica es un poco de sentido común, ni más ni menos. Reglas tan sencillas como “si alguna operación puede ser repetida más de una vez, crea una función que la realice“. De esta forma sólo tendrás que corregir el código en un único sitio cuando falle (que fallará, casi seguro, al menos una vez). Si se tiene esto en cuenta, la PP es tan sencilla como (teniendo ya en mente el programa y, al menos, definidas sus partes básicas):

1. Definir las constantes y variables que necesitarás a priori, ya sean globales (sí, sí, las variables globales son válidas si se emplea el sentido común)  o locales.
2. Definir las funciones y procedimientos que se necesitan.
3. Indicar el flujo del programa desde el inicio hasta el final.

No parece complicado, ¿verdad? En realidad no lo es, de ahí mi favoritismo por esta metodología de trabajo. Básicamente sería algo como esto:

Bloque de variables y constantes

Bloque de procedimientos y funciones:
Procedimiento 1();
Procedimiento 2();
Función 1();

Función principal donde se controla el flujo del programa:
Inicio del programa;
Mis cálculos;
Llamo a Procedimiento 1();
Llamo a Función 1();
Llamo a Procedimiento 1();
Más cálculos;
Fin del programa

1. Lo primero que salta a la vista: sencillez y claridad. Cualquiera entiende esta forma de trabajo fácilmente, se adapta pronto y, también, se adopta pronto.
2. Es fácil seguir un programa, sólo hay que seguir el “hilo”.
3. Alguien que no haya escrito el programa puede coger el código y entenderlo con cierta facilidad (esos comentarios que tan poca gente pone de forma adecuada… ¡¡ay!! ).
4. Modificarlo es sencillo y rápido.
5. ¿He dicho ya sencillez y claridad?

¿Problemas principales de esta metodología?:

1. No está muy indicada para trabajar en grupo, dado que tú te lo comes y tú te lo guisas hasta el final. Si te organizas muy bien sí puedes trabajar en grupo (por ejemplo se desarrollan cada uno de los procedimientos por separado y luego uno los junta todos en el código final y se prueba), pero se complica mucho el asunto por las variables globales y locales, ya que no sabes qué va a hacer el otro con ellas.
2. Si el programador no es metódico y responsable en su trabajo puede liarla, y bien, con las variables globales y locales, dada su libertad de uso.
3. Si el programa es muy grande, te pueden salir auténticos chorizos de código, pero esto es algo que siempre puedes arreglar si eres una persona ordenada y divides el código en partes que incluyes en procedimientos. Veamos un ejemplo de este último punto:

Esto sería el código “spaguetti”, que se suele llamar (indeseable):

Procedimiento 1()(
Mucho código por aquí...
Sigue mi código porque tiene muchos cálculos...
Más código...
Y más código...
...
(y muchas líneas después...)
Más código...
Fin del Procedimiento
)

Procedimiento 1()(
Mucho código por aquí...
Sigue mi código porque tiene muchos cálculos...
Llamar a SubProcedimiento 1_1(); (esto contendrá parte de los cálculos)
Llamar a SubProcedimiento 1_2(); (esto contendrá otra parte de los cálculos)
Fin del Procedimiento
)

Tan buena es la PP que cualquiera puede hacer un programa con escasos conocimientos del lenguaje que elija, lo cual ha dado lugar a auténticas chapuzas, por supuesto, que, aún así, visualmente hacían lo que debían. Y es que no siempre “el fin justifica los medios“. Es fácil hacer algo chapucero que ofrezca el resultado esperado, pero que mañana, cuando haya que modificarlo, no haya por donde cogerlo.

La libertad que ofrece este modelo es, a su vez, su mayor peligro. Los que hayan vivido en el mundo empresarial desde el año 1990 hasta prácticamente el 2005 habrán podido experimentar en vivo el boom de universitarios “informáticos” que eran la “leche“, pero que no aplicaban precisamente las mejores técnicas de programación. Me incluyo yo ahí. El primer año que trabajé como programador de Visual Basic fue el de mi aprendizaje, con el viejo sistema de prueba/error: hacía un programa y aprendía Visual Basic a la vez. Todo iba, en realidad, pero al año siguiente, al tener que coger y aumentar funcionalidades al programa, aparecían los problemas: mal diseño, mala codificación, y nula documentación. “Nunca máis” me dije, y empecé a aplicar buenas prácticas y a diseñar un manual para la empresa de “diseño de aplicaciones en La EMPRESA” que el resto de programadores debían seguir (yo fui el primero de la empresa y luego llegaron 4 más). Hoy soy un hombre feliz, y cuando veo el código de aquellos programas, aún sé qué hacen y como modificarlos .

Con la introducción masiva de Java (POO) en nuestras vidas de programador, se ha perdido este encanto. Si bien C++ ya existe desde hace muchos años, la auténtica revolución del nuevo ejército de programadores POO llegó con Java. Antes, la guerra era tal que así:

• Hola buenos días.
• Hola qué tal.
• ¿Tú en qué programas?
• Yo en Visual Basic.
• Bah, eres un programador junior con poca idea, VB es de “mariquitas” que no saben usar POO. Lo auténtico es el C++, eso si que es para machotes, con sus punteros a Null y sus miles de líneas de código eficiente…
• Ya bueno, yo es que tengo que hacer un programa de gestión para dentro de un mes y con C++ tardo 3 meses…
• Bueno, pero sería altamente eficiente ¡y con código reusable!
• Sí, bueno, pero si le doy de plazo 3 meses al cliente (con un coste 3 veces superior) me dice que lo haga Rita.
• No tenéis ni idea de manejar clientes…

Ahora… la cosa es tan diferente… que si .NET, que si Java, que si C++… pero ninguno de estos emplea los métodos tradicionales, son todos (básicamente) POO: ¡¡ nos están aniquilando !! Ya no hay guerra, con lo divertida que era. Bueno, que ya empiezo a desviar el tema.

En la próxima entrada analizaré brevemente la POO y os ofreceré mi punto de vista final (que ya vais viendo por dónde va). La verdad es que el tema es muy amplio, pero sólo trato de dar una ligera aproximación, porque si no, nos da para un libro en vez de una página. Espero vuestras opiniones.

1. Lots of Insipid and Stupid Parenthesis, que decían los angloparlantes

Siguiendo el consejo de Macluskey, me he decidido a escribir una pequeña serie relacionada con lo que más entiendo y de lo que sobrevivo, la informática. Ya sé que esto suele ser un tema aburrido para los que no son informáticos y, si es demasiado técnico, hasta para los que son informáticos, por lo que voy a tratar los temas de manera algo superficial y poco técnica, para mayor comprensión popular de la gente que no ha visto estos asuntos en su vida, aunque le puedan sonar de algo. Además, no pondré código fuente, si es lo que estabais temiendo.

También debo decir que alguna opinión personal aparecerá por aquí, si bien espero que sean pocas y razonadas.

Es evidente que, al ser un tema centrado en tecnologías de informática, podrá resultar completamente aburrido para gente que no tenga el más mínimo interés en estas cosas pero, como decía mi abuelo, “a caballo regalado no le mires el dentado…” que ya sé que no tiene nada que ver con esto que estoy diciendo, pero es que a mí siempre me ha hecho gracia este refrán.

Así, a bote pronto, la temática que tendrá la serie será:

• Programación procedural clásica (PP) vs Programación orientada a objectos (POO): parte 1 y parte 2.
• Sistemas cliente-servidor (2 capas) vs Sistemas multi-capa (habitualmente 3).
• Servicios web (WS), Arquitectura orientada a servicios (SOA) y demás zarandajas de la “globalización” de los programas.

Los dos primeros temas son controvertidos como el que más, y tienen siempre seguidores y detractores, que van desde lo superficial a lo enfermizo. No es este mi caso, yo tengo las ideas claras respecto a ellos, y trato de elegir siempre lo más conveniente para cada caso, lo cual tampoco es fácil y no siempre se acierta.

Espero poder empezar con estos temas cuanto antes para que me podáis ir dando vuestra opinión al respecto.

Un saludo a todos, y hasta pronto.