Hola Comunidad!.

La pregunta puede que necesite una respuesta muy grande.Y hace mucho calor.

Veréis, ¿seguís un  patrón a la hora de realizar cualquier tipo de programa ?.
Con esto quiero decir, ¿ tenéis tendencia a colocar determinadas partes del código
en un sitio determinado ?. Ya sea un modulo, un formulario, etc.

A lo mejor algunos meten todo el código en el mismo formulario, no hace un modulo.
O hace varios formularios con módulos comunes. ¿Lo haces de una manera siempre ?.
Por que es la que os gusta, por costumbre de manera de hacer el programa.Por manía,por vicio.
(Claro que hay cosas que depende del propio programa).

Casi se puede preguntar. ¿ Que pasos seguís para estructurar el programa o desarrollo del mismo ?.
Sabiendo que es un lenguaje orientado a eventos, el código es un reflejo de esos botones, formularios,etc.

Lo mismo la pregunta no tiene respuesta, por que abarca mucho.
Que conste que lo he intentado.  

===================
Gambas Básico
"No es un bug, es una característica no documentada"

A mi personalmente me gusta crear métodos y que al presionar un botón llame al método... Por aquello de que en java si borras el botón te cargas todo el código que contenia, pero si solo contenia la llamada al método no pierdes nada... En gambas no lo hago siempre, solo si me acuerdo..

Así mismo pongo una pequeña descripción antes del método con un comentario...
Las varibles públicas las empiezo a meter en Módulos (vi a jsbsan que así lo hacia)

Yo también procuro meter todas las rutinas o funciones en un módulo, aun que solo las use una vez... me suelen quedar unos fuentes un poco más comprensibles, ya que no soy un adicto a los comentarios.

Hola!.

Entonces, prácticamente lo que sea formulario, solo metéis lo que es código de esos
componentes que están en ese formulario.Minimizando mucho el código en este formulario y
repartiéndolo en un modulo común.Haciendo llamadas a este.

Con eso ganáis en limpieza de código, siempre que no masifiquéis el modulo claro.

Por un lado:
- Variables publicas en un modulo común .
- Minimizar el código en los formularios.
- Hacer llamadas desde los componentes de formulario al modulo.

Espero que se animen mas compañeros, siempre que tengan tiempo.

Saludos.

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Yo no soy programador, programo por hobby, aunque algunas de las aplicaciones que he desarrollado me parecen interesantes (modestia aparte!, jajaja).

Coincido con Shell, en tener un módulo para las variables públicas comunes.

Por otro lado, trato dentro de lo posible de trabajar mucho con clases, entonces todas las funciones y demás de cada clase están incluídas en estas.
Por ejemplo, si trabajo con base de datos, tengo una clase que se encargue solamente de eso, y las otras clases que interactúan con la base de datos no tienen una sóla línea sql y trabajan todo a través de la clase de la base de datos... Trato de separar el código así...

Y suelo comentar bastante... porque por ahí pasa el tiempo y si tienes que volver a trabajar sobre algo que desarrollaste hace mucho, tener comentarios y referencias ayuda....

Citar:

Por un lado:
1 - Variables publicas en un modulo común .
2 - Minimizar el código en los formularios.
2 - Hacer llamadas desde los componentes de formulario al modulo.

1. Variables públicas: eso es exactamente hacer un módulo con variables globales, la única diferencia es que te obliga a escribir el nombre del módulo cada vez que querés usar una de sus variables, en vez de poder escribir sólo el nombre de la variable. No hagas eso, es muy poco recomendable. Si tu intención es seguir utiilzando el paradigma modular y estructurado, deberías procurar minimizar el uso de variables globales y para lograrlo debés olvidarte de amontonar variables en un módulo porque ello no aporta nada a que la arquitectura de tus aplicaciones sea más clara o manejable, más bien lo contrario.
   
2. Formularios: el principio no es minimizar el código de los formularios, sino que cada formulario contenga solamente código que manipula sus propios controles gráficos y llamadas a rutinas alojadas en módulos.
   

La programación modular y estructurada es precisamente eso: hacer uso de las estructuras de control para estructurar el flujo de ejecución del programa y de rutinas y módulos para modularizarlo. Ahora bien, este estilo de programación nada te dice sobre cómo hacer esa modularización. Un programa de este estilo es un conjunto de rutinas (agrupadas en módulos) que se comunican a través de sus parámetros: hay que intentar tanto como sea posible que las rutinas sólo utilicen la información provista en sus parámetros, evitando el uso de variables globales.

El problema es que esto fácilmente puede conducir a rutinas con extensas listas de parámetros y eso es un problema por hace que el código sea difícil de comprender y en consecuencia hace que sea difícil de mantener y propenso a errores. Una muy buena modularización ayuda mucho: una pauta muy informal sería que una rutina no debería contener más de 15 o 20 líneas; pero mucho mejor que eso es comprender que las rutinas deben ser cohesivas y que se debe disminuir el acoplamiento tanto como se pueda.

Cohesión (aplicado a rutinas). Una rutina debe hacer sólo una cosa, su código debe mantener siempre el mismo nivel de abstracción. Una forma sencilla de controlar esto es elegir nombres significativos para las rutinas (verbo + sustantivo: imprimirEtiquetas()) y chequearlo contra el código: si al leer el código caemos en la cuenta de que deberíamos ampliar el nombre de la rutina para que refleje lo que en realidad hace su código, es que la rutina no es cohesiva.

Lo más recomendable es tomar algo de la programación orientada a objetos y crear módulos que contengan rutinas y variables que guarden una alta cohesión. La cohesión a nivel de módulo implica que las rutinas que contiene deben tener una finalidad común. En programación modular y estructurada los módulos se crearon mayormente para permitir la construcción de bibliotecas de funciones. En vez de eso, si aplicás una idea básica de la programación orientada a objetos podés crear módulos que aglutinen rutinas pero en relación a los objetos del dominio, por ejemplo, un módulo persona que contenga todas las funciones que manipulan los datos de personas y las variables que guardan los datos de las personas. En una escala evolutiva este módulo sería un ancestro (por lo tanto, mucho menos evolucionado) de la clase "persona".

Bueno, tenía la intención de escribir más, pero en casa estamos por almorzar y tengo a mis peques saltándome encima.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Bueno os cuento mi experiencia.

Como dice fabianfv

Citar:

deberías procurar minimizar el uso de variables globales

El uso de variables globales en malo en si, porque llega un momento que no tienes el control de lo que le pasa a la variable, y cuando quieras ampliar el programa, tienes un problema...

Para programas pequeños, puede ser una forma fácil de hacer las cosas, pero para programas de gran tamaño, te trae más problemas que beneficios...osea que lo mejor es NO USARLAS.

Citar:

amontonar variables en un módulo porque ello no aporta nada a que la arquitectura de tus aplicaciones sea más clara o manejable, más bien lo contrario.

Aqui discrepo con fabianfv. Yo cuando las uso, las agrupo en un módulo (lo llamo "var") y voy poniendo comentarios de para que sirven y que hacen.
Lo hice asi, porque en algunas aplicaciones "medianas" llego un momento en que no perdía el control de cuales definidas, que hacian, etc... porque mi memoria no daba abasto, e iba siempre arriba y abajo revisando el código fuente, para saber como las habia llamado   ... Al tenerlas en un módulo lo tenia siempre de referencia (Truco: habria el gedit, e iba escribiendo las variables, para tenerlas siempre a la vista).

Pero cuando los programas son grandes, al usar variables globales, a la larga te cuesta mas ampliarlo (le hechas mas horas de la cuenta) y finalmente te impiden ampliarlo...

Lo mejor es planificarse muy bien el programa, saber que necesita el usuario/cliente y crearte diagramas que te ayuden a ver los problemas y resolverlos (siempre empezar desde una visión general y luego poco a poco ir al detalle)



Os dejo una entrada que os puede ser muy util, lo hablamos una vez en el foro, y lo pase a mi antiguo blog, para no perderla:
Paso de valores de variables de un formulario a otro:
http://jsbsan.wordpress.com/2010/11...orm-desde-otro/

arubioc:

Citar:

ya que no soy un adicto a los comentarios.

Te tienes que volver adicto....  

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Citar:

Citar:

    amontonar variables en un módulo porque ello no aporta nada a que la arquitectura de tus aplicaciones sea más clara o manejable, más bien lo contrario.

Aqui discrepo con fabianfv. Yo cuando las uso, las agrupo en un módulo (lo llamo "var") y voy poniendo comentarios de para que sirven y que hacen.
Lo hice asi, porque en algunas aplicaciones "medianas" llego un momento en que no perdía el control de cuales definidas, que hacian, etc... porque mi memoria no daba abasto, e iba siempre arriba y abajo revisando el código fuente, para saber como las habia llamado ... Al tenerlas en un módulo lo tenia siempre de referencia (Truco: habria el gedit, e iba escribiendo las variables, para tenerlas siempre a la vista).

Bueno, veo que no me estás dando el crédito que me merezco  

Lo que estás contando precisamente es buen un ejemplo de por qué no es una buena idea crear un módulo  donde meter variables globales (bueno ... públicas, pero a fin de cuentas es lo mismo).

El hecho de que hayas necesitado escribir abundantes comentarios para explicar el uso que le das a esas variables es una clara muestra de que están desligadas del contexto en el que se usan.

Esa carencia de contexto es lo que crea el problema, en primer lugar, y la solución a ello no es añadir muchos comentarios que a la larga es altamente probable que queden desactualizados (es decir, que lejos de aclarar algo lo oscurecen, porque finalmente brindan información incorrecta).

Entiendo que meter todas las variables a un módulo te haya resultado mejor si la situación anterior era que estuvieran desperdigadas por módulos y formularios sin un criterio claro.

Pero, como dije antes, lo mejor es (y esto es propio de la POO) enlazar el dominio del problema con el dominio de la solución. Es decir, colocar rutinas y variables en módulos creados específicamente para manejar la información relativa a un objeto del dominio. Por ejemplo (suponiendo una aplicación que deba manipular información de personas, clientes y proveedores): un módulo que reúna las variables y funciones relativas a personas, otro para reúna las variables y funciones relativas a los clientes y otro para los elementos correspondientes a los proveedores.

De ese modo, se mejora la modularización a nivel de módulos. Se evita tener módulos con gran cantidad de variables/funciones que guardan poca relación entre sí (baja cohesión), es decir los módulos contienen variables y funciones con un alto grado de cohesión funcional.

Como consecuencia, resulta mucho más difícil meter la pata, es decir, usar de modo incorrecto una variable o una función (porque están ligadas a su contexto) y ello hace innecesario escribir gran cantidad comentarios para explicar para qué se usa cada elemento, ya que la asignación de nombres descriptivos es suficiente.

Espero haber sido claro.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.

FabianFV

Citar:

enlazar el dominio del problema con el dominio de la solución

Esta frase es muy buena... seguiré tus consejos..   

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Compañeros.

Son muy buenas las respuestas.Poco tratamos de como debemos hacer un programa como aquello de "los buenos modales".
Aquí seria en programación. La resolución de un problema llevado a un ordenador con un orden o manera de afrontarlo para
convertirlo a un código bien distribuido, elegante.  

Fabian:

Tus explicaciones son muy buenas, claro que tu vas ya con la intención de la POO.
El tratamiento del problema, aislarlo a módulos concretos según variables, funciones, procedimientos que
pertenecen solo de ese subproblema.

Haciendo de un problema. Pequeños problemas mas fáciles de solucionar individualmente, creo que
era la abstracción.El termino, claro.

Como tu dices, no nos enseñan o no nos educan a como crear esos módulos.
Aprendemos un conjunto de instrucciones, una serie de normas, pero el desarrollo de
un problema se queda corto, por mucho libro que leas.

Julio:

Tu siempre haces muestra de un interés enorme por aprender y compartir lo que haces con nuestra comunidad.
Aprendemos unos de los otros, de los errores y los aciertos. Como tu también dices hay que plantearse muy bien
el problema.Lo que no es fácil es el desarrollo de ese problema.O dejarlo, "bordado".

Una mente abierta a un problema no es siempre fácil, una mente de un programador.

Pues nada, a estudiar.Lo que se pueda.


Saludos.

===================
Gambas Básico
"No es un bug, es una característica no documentada"