Introducción

Escribo el siguiente artículo con la finalidad de hacer entender a los usuarios las ventajas e inconvenientes de la programación visual para que cada uno pueda ser crítico con sus conocimientos y métodos de programación.

El objetivo principal es hacer ver que para una correcta programación no hace falta abusar de la programación visual ya que denota poca técnica y a la larga no es productivo. Como siempre es un documento conceptual y cada uno podrá aplicarlo en el lenguaje que utilice, pero sobre todo le servirá a gente auto-didacta o gente que no tenga en cuenta la forma de cómo programa.

Programación en modo consola

Bajo mi punto de vista, una persona que empieza a programar debería empezar por un lenguaje en modo consola, para ello entre otros existe pascal o Ansi C donde el usuario puede adquirir los conocimientos básicos sobre el lenguaje referente a algoritmos, especificación, estructura de datos y sintaxis.

También es importante para ampliar conocimientos sobre programación modular, clase y herencia o la creación de librerías/units de parámetros no dependientes con un programa principal. No es muy difícil darse cuenta de las ventajas principales que nos ofrecen todos estos conceptos, hablaremos un poco más de ellos a continuación.
La programación modular, nos permite crear rutinas en forma de módulo o función que en un programa principal se repetirían muy a menudo, de ésta forma podremos ahorrar líneas y tan solo hará falta llamar a una función o procedimiento y pasar los parámetros necesarios creando una rutina genérica para todo nuestro programa.

Ampliando el concepto modular, si en vez de utilizar las funciones o procedimientos en nuestro programa principal, creamos con ellos una librería o UNIT tendremos la ventaja de poder aprovecharlo en futuros programas con lo que ahorraremos tiempo y en caso de una empresa dinero. En caso de querer hacer nuestras propias librerías es importante pensar en la estructura de datos y crearla para que desde el programa principal no haya dependencia con las variables de la librería, además  terceras personas de ésta forma podrán aprovechar las librerías.

Una de las ventajas principales que nos permite ésta independencia es que si años después de crear una aplicación, requiere ser modificada solo deberemos cambiar la estructura de datos de la librería y no la del programa principal. Así por ejemplo si se trata de una aplicación de un banco, la cual envía y recibe parámetros con una base de datos, el programa que utilizan los operarios nunca cambiará y no hará falta formarles en un nuevo software. Veamos la idea de forma gráfica para que se entienda:


Otra ventaja en el uso de librerías o units, es que la entrada y salida de datos, puede personalizarse según el idioma del usuario, por ejemplo si el programa pide un número, dirá:


Si previamente el usuario del programa puede seleccionar el idioma, el programa principal puede llamar al modulo “idiomas” y generar la entrada y salida de datos en el idioma que elija el usuario.

Estos dos ejemplos sirven para complementar los conceptos citados, seguramente hay otras formas de hacerlo o muchos más ejemplos que se me ocurren, pero cada lector, si ha entendido lo que se transmite entenderá que se puede sacar mucho provecho teniendo buenos métodos en programación y trabajando mejor el diseño inicial. Para una empresa, encontrar gran cantidad de errores en un producto casi acabado es una gran pérdida de tiempo, por eso es importante realizar un buen diseño de las especificaciones del problema o objeto de un cliente.

Programación orientada a objetos (POO)

Sobre POO no me extenderé demasiado, ya que es algo transitorio y muy importante del paso de programación a modo consola a la programación visual. Una de las ventajas es la creación de objetos propios generados por un “Constructor” como el que tiene Delphi. En éste caso toma gran importancia el concepto de “Clase y Herencia”.

Programación Visual

Éste apartado bajo mi punto de vista es de especial interés en cuanto diseño e “interface”  de una aplicación se refiere y no por ello lo más importante de la programación, es por ello que toda persona que empieza a programar, siempre recomiendo el uso de un lenguaje no visual ya puede dar malos hábitos y se pierde gran cantidad de conceptos fundamentales en programación como los destacados en el primer apartado.

La programación visual, la deberíamos considerar una ventaja estética en la actualidad y no como una alternativa de programación y me gustaría dar a entender a los lectores que es esencial dar a ésta un buen uso ya que debería ser solo  un Front-End gráfico, la programación real debe ir independiente a éste en lo que se puede conocer como Back-End. Ésta diferenciación nos puede dar ventajas como las comentadas en el ejemplo de la aplicación del banco del primer apartado.

En gran cantidad de foros, páginas o blogs veo códigos de personas que hacen un mal uso en la programación visual como el anidar gran cantidad de líneas de código dentro los objetos (botones, pictures…) haciendo que la aplicación sea única ya que difícilmente ése código se podrá aprovechar en posteriores programas. Lo ideal sería desde los objetos, llamar a funciones o procedimientos creados en librerías externas o en caso de tener claro que no se aprovechará código en un futuro, en el mismo programa principal.


Entonces queda una pregunta pendiente “Siempre se debe poner el código fuera del cuerpo de los objetos?”. La respuesta claramente es que no ya que si un botón solo tiene dos líneas de código es poco productivo escribir 5 más para ponerlo dentro de una función y llamarlo. Eso queda a juicio de cada lector, pero es importante ser consciente de ello, sobre todo si en un futuro crearemos aplicaciones similares o se trata de una empresa que continuamente se hacen programas similares.

Así que la programación visual, como conclusión dentro de un ámbito sobre todo empresarial es algo puramente estético, ya que es lo que el cliente tiene a primera vista. De poco sirve una aplicación de gran atractivo visual si tiene poca eficiencia y es lenta, en caso contrario, si la programación es muy buena y el diseño malo, el cliente también tiende a quejarse paradójicamente.

Despedida y conclusión.

Espero que el documento les haga pensar, primero a aquellos que empiecen con algún lenguaje de programación, aunque quizá los conceptos citados ni los conozcan, son necesarios para aprender a programar ya que sin ellos no se puede hacer nada.

Para los que sepan programar, espero que algún que otro concepto sirva de inspiración, o si dentro la metodología que utilizan, aplican todo lo dicho espero que sean conscientes que a los “nuevos” en programación se les debería hacer entender un camino lógico y no lanzarles en lenguajes como el Visual Basic o directamente el Delphi (para no discriminar) sin antes pasar por una programación a modo consola.

Si eres nuevo y buscas un lenguaje de programación para empezar a aprender, yo personalmente, recomiendo la instalación de Delphi, donde lo ideal es empezar con la programación en modo consola, y acabar con programación visual una vez se tengan conceptos claros y una metodología de programación.

Buen post! Y sí, estoy de acuerdo con LH en lo que dijo..

Un saludo!

Lo que pusiste ahi sobre la programacion orientada a objetos, esta muy mal...
El resto del texto masomenos, de lo que en realidad hablas es de separar la capa de logica de la aplicacion, de la de vista... no tiene tanto q ver con consola o no consola, sino como organizar el codigo en distintos binarios ( incluye librarias estaticas y dll ), con el fin de tener que modificar lo menos posible...

Buenas,

Aunque hace tiempo del ultimo post. Me gustaria decir, que gracias por la aclaración a los que queremos conocer el mundo de la programación. Gracias por darnos una pequeña base de por donde empezar, para no cojer vicios, y aprender desde el inicio o la base, y no desde la carcasa. En serio muchas gracias. Me ha sido de ayuda para saber por donde empezar este post.