Hola Comunidad!.

Con el paso del tiempo vamos mejorando nuestra aplicación.Creando módulos,clases,etc.
Cuando comenzamos no tenemos ni idea que son los objetos y aun así muchos de nosotros
llevamos tiempo y seguimos con poca experiencia en la POO. Yo me incluyo.Pero estoy en ello.  

Os cuento. Hice una pequeña aplicación para el control de una biblioteca.En este ejemplo,
no he usado una base de datos "aun", por que no era la finalidad.La finalidad era mejorar
la aplicación.

Se trata básicamente de un formulario con una serie de cajas de texto con los datos del libro.
Al pulsar en el botón añadir, un código isbn o un titulo del libro se añade a una lista. Si hacemos
click en el elemento de la lista se mostraran los datos del libro en otro formulario según el indice
que marca la listbox. Simple

Bien. La aplicación ha ido cambiando de la siguiente manera:

Biblioteca1:

-FormPrincipal
-FormMuestaLibro

Biblioteca2:

-FormPrincipal
-FormMuestaLibro
- Módulos Variables
- Módulos Funciones

Biblioteca3:

- FormPrincipal
- FormMuestraLibro
- Clase libro
- Clase biblioteca (esto no estoy seguro de que sea necesario).

La clase biblioteca incorpora todas los métodos para agregar un libro, borrar,etc.
Y la case libro, pues solo las propiedades de un libro.

La finalidad es eliminar la mayoría del código de los formularios y hacer uso de funciones, métodos
y como meta hacer uso de las clases.

¿ Se debería incluir los métodos de trabajar con los libros en la clase libro o seria mejor una clase para trabajar con ella ?.
No he hablado de herencia.

¿ Seria mejor usa una colección de objetos o un array de objetos ?.

Saludos.

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

No tengo mucha idea de poo, pero...

Citar:

¿ Se debería incluir los métodos de trabajar con los libros en la clase libro o seria mejor una clase para trabajar con ella ?.

Para eso tienes la clase Biblioteca, donde podras ingresar nuevos libros, borrar libros deteriorados, prestar libro, estadisticas de prestamos, etc...

Citar:

- Clase biblioteca (esto no estoy seguro de que sea necesario).

La clase biblioteca, ademas puede manejar otros objetos (revistas, cd, dvd ), y tener los mismos métodos para manejarlos (agregar, borrar, prestar,estadistica,etc). Por eso es necesario que la tengas.

Citar:

¿ Seria mejor usa una colección de objetos o un array de objetos ?.

Pienso que seria mejor usar una coleccion, ya que tendras indentificado cada libro por su ISBN.

Saludos

Editado:
Mirate este  Enlace
donde comenta como hacerlo. Aqui lo que hace es usar una clase "Material", de donde heredan libros, revistas, cd, y en la clase "Material", es la que tiene los métodos para manejarlos... Ademas tiene encuenta lo que hacen los socios.

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

Hola Julio.

Tratare de ver el problema para ver la diferencia con colección y arrays.

A veces en la programación miramos la facilidad y otras el ahorro de memoria.
Lo de ahorro de memoria viene de antiguo, que miraban hasta el ultimo "K".
Pero claro, ahora con tanto giga.

Por eso lo de la pregunta. A lo mejor la colección ocupaba mas.
La colección es una variante de array de objeto.

Gracias por el enlace.


Saludos.

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

Citar:

A veces en la programación miramos la facilidad y otras el ahorro de memoria.
Lo de ahorro de memoria viene de antiguo, que miraban hasta el ultimo "K".

Si, me acuerdo que cuando programa en basic, lo miraba, ahora no lo hago...     

Por cierto  ¿como saber cuanto ocupa un programa en la memoria ahora con gambas, y en modo de ejecución? ¿hay limites...?

Saludos

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

Shell escribió: [Ver mensaje]

Hola Julio.

Tratare de ver el problema para ver la diferencia con colección y arrays.

(...)

Por eso lo de la pregunta. A lo mejor la colección ocupaba mas.
La colección es una variante de array de objeto.

Saludos.

En gambas hay que tener en cuenta que los arrays son objetos y son dinámicos en cuanto a su tamaño. Una colección en gambas siempre guarda un valor de tipo Variant, así que siempre va a ocupar un poco más de memoria que un array, a menos que se trate de un array de tipo Variant, en cuyo caso es probable que la memoria que ocupe sea casi igual.

Podemos realizar consideraciones teóricas sobre la implementación típica de una array vs una colección, pero no tendría sentido. En todo caso habría que preguntarle a Benoit que es quien conoce realmente la implementación.

Preocuparse por la memoria que va a ocupar una colección en comparación a un array por lo general no tiene sentido, a menos que se trate un tipo de aplicación muy particular que requiera un muy cuidadoso diseño porque tiene requerimientos de rendimiento muy altos o a menos que tengamos la necesidad de almacenar decenas de miles de elementos.

También podemos pensar en la velocidad de las diferentes operaciones que se pueden realizar sobre un array y una colección, pero la situación sería similar: para estar seguros deberíamos conocer la implementación y en definitiva esas diferencias son irrelevantes en la mayoría de las situaciones que se nos pueden plantear. Entonces, no es algo que necesitemos conocer de antemano, sino que es algo que deberíamos preguntarle a Benoit cuando nos enfrentemos a una situación que nos obligue a considerar el rendimiento.

Lo más importante en la elección de un array vs una colección es lo siguiente:

* Una colección permite recuperar sus elementos a partir de una clave que es una cadena de texto que obviamente es fácil de recordar. Para lograr lo mismo con un array es necesario usar una lista de constantes o una enumeración.

* En un array podemos insertar elementos sin considerar el orden en que se insertan ya que se les asigna automáticamente un índice que será consecutivo empezando por cero. Al usar una colección debemos ser conscientes de qué clave asociar con cada valor a insertar.

* Un array mantiene el orden en que se insertaron sus elementos y ello sólo cambia al insertar nuevos elementos en posiciones intermedias o al reordenarlo. ¿Una colección mantiene el orden en el que se guardaron sus elementos mientras no se añadan otros? En gambas parece que sí (yo creo que sí), pero habría que confirmarlo porque ello podría ser un efecto no determinístico.

* Relacionado con el item anterior, un array se puede ordenar y reordenar en cualquier momento mediante un método interno. Las colecciones no tienen métodos internos de ordenamiento, lo que podría estar sugiriendo que no pueden asegurar la recuperación ordenada de sus elementos.

* Al asignar a un array un valor en una posición pre-existente (con un índice usado previamente) obviamente reemplazamos el valor antiguo con el nuevo. Al asignar un valor a una colección usando una clave ya existente en ella, también sobreescribimos el valor que estaba asociado a esa clave.

* Al intententar recuperar un elemento de un array mediante un índice que no existe, se obtiene un error en tiempo de ejecución. En cambio, al intentar recuperar un elemento de una colección mediante una clave inexistente, no se obtiene ningún error.

* Los arrays pueden contener valores NULL, pero no las colecciones, ya que asociar el valor NULL con una clave de una colección equivale a eliminar ese par.

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

Speed Books: informática libre.

fabianfv escribió: [Ver mensaje]

Shell escribió: [Ver mensaje]

Hola Julio.

Tratare de ver el problema para ver la diferencia con colección y arrays.

(...)

Por eso lo de la pregunta. A lo mejor la colección ocupaba mas.
La colección es una variante de array de objeto.

Saludos.

En gambas hay que tener en cuenta que los arrays son objetos y son dinámicos en cuanto a su tamaño. Una colección en gambas siempre guarda un valor de tipo Variant, así que siempre va a ocupar un poco más de memoria que un array, a menos que se trate de un array de tipo Variant, en cuyo caso es probable que la memoria que ocupe sea casi igual.

Podemos realizar consideraciones teóricas sobre la implementación típica de una array vs una colección, pero no tendría sentido. En todo caso habría que preguntarle a Benoit que es quien conoce realmente la implementación.

Preocuparse por la memoria que va a ocupar una colección en comparación a un array por lo general no tiene sentido, a menos que se trate un tipo de aplicación muy particular que requiera un muy cuidadoso diseño porque tiene requerimientos de rendimiento muy altos o a menos que tengamos la necesidad de almacenar decenas de miles de elementos.

También podemos pensar en la velocidad de las diferentes operaciones que se pueden realizar sobre un array y una colección, pero la situación sería similar: para estar seguros deberíamos conocer la implementación y en definitiva esas diferencias son irrelevantes en la mayoría de las situaciones que se nos pueden plantear. Entonces, no es algo que necesitemos conocer de antemano, sino que es algo que deberíamos preguntarle a Benoit cuando nos enfrentemos a una situación que nos obligue a considerar el rendimiento.

Lo más importante en la elección de un array vs una colección es lo siguiente:

* Una colección permite recuperar sus elementos a partir de una clave que es una cadena de texto que obviamente es fácil de recordar. Para lograr lo mismo con un array es necesario usar una lista de constantes o una enumeración.

* En un array podemos insertar elementos sin considerar el orden en que se insertan ya que se les asigna automáticamente un índice que será consecutivo empezando por cero. Al usar una colección debemos ser conscientes de qué clave asociar con cada valor a insertar.

* Un array mantiene el orden en que se insertaron sus elementos y ello sólo cambia al insertar nuevos elementos en posiciones intermedias o al reordenarlo. ¿Una colección mantiene el orden en el que se guardaron sus elementos mientras no se añadan otros? En gambas parece que sí (yo creo que sí), pero habría que confirmarlo porque ello podría ser un efecto no determinístico.

* Relacionado con el item anterior, un array se puede ordenar y reordenar en cualquier momento mediante un método interno. Las colecciones no tienen métodos internos de ordenamiento, lo que podría estar sugiriendo que no pueden asegurar la recuperación ordenada de sus elementos.

* Al asignar a un array un valor en una posición pre-existente (con un índice usado previamente) obviamente reemplazamos el valor antiguo con el nuevo. Al asignar un valor a una colección usando una clave ya existente en ella, también sobreescribimos el valor que estaba asociado a esa clave.

* Al intententar recuperar un elemento de un array mediante un índice que no existe, se obtiene un error en tiempo de ejecución. En cambio, al intentar recuperar un elemento de una colección mediante una clave inexistente, no se obtiene ningún error.

* Los arrays pueden contener valores NULL, pero no las colecciones, ya que asociar el valor NULL con una clave de una colección equivale a eliminar ese par.

El tamaño que ocupa en la memoria cada tipo de datos esta documentado aqui. En algunos casos, suelen haber memory leaks (no por definición) dentro de las aplicaciones.
Un ejemplo con el cual me he encontrado es el siguiente. En un proyecto, tengo un formulario que al abrirse muestra un IconView con aproximadamente 100 iconos. Al principio, luego de abrir este formulario la memoria usada subía en promedio 10-20 MB, sin embargo, al cerrarlo, esta no bajaba a la normalidad (aunque el formulario no era persistente, este era destruido al cerrarlo). Una solución fácil, ejecutar IconView.Clear() dentro de Form_Close(). Eso soluciono todo. A raíz de esto, cada vez que trabajo con alguna estructura de datos que estoy seguro va a necesitar demacrada memoria, me aseguro de asignarle el valor Null al finalizar el trabajo, incluso con formularios. Comprobado de que el uso de memoria es mucho menor al implementar esto.

Volviendo al tema del diseño de una aplicación. Las aplicaciones gráficas en gambas, por diseño, suelen seguir el patrón MVC, solo que la Vista y el Controlador se "superponen". En la practica, lo mejor es abstraer todo código que maneje estructuras de datos (ya sea usando la memoria en el tiempo de ejecución o una base de datos) de el código que maneje la parte gráfica, donde suele haber interacción con el usuario.

Para saber que es mas eficiente, si usar un Array o una Colección, depende como almacenes los datos. En ambos casos, puede usar la IDE para perfilar la aplicación y saber exactamente cuanto tiempo tarda en ejecutar cada función.

Hola sebikul. Gracias por el aporte de tu propia experiencia.

sebikul escribió: [Ver mensaje]

Un ejemplo con el cual me he encontrado es el siguiente. En un proyecto, tengo un formulario que al abrirse muestra un IconView con aproximadamente 100 iconos. Al principio, luego de abrir este formulario la memoria usada subía en promedio 10-20 MB, sin embargo, al cerrarlo, esta no bajaba a la normalidad (aunque el formulario no era persistente, este era destruido al cerrarlo). Una solución fácil, ejecutar IconView.Clear() dentro de Form_Close(). Eso soluciono todo. A raíz de esto, cada vez que trabajo con alguna estructura de datos que estoy seguro va a necesitar demacrada memoria, me aseguro de asignarle el valor Null al finalizar el trabajo, incluso con formularios. Comprobado de que el uso de memoria es mucho menor al implementar esto.

gambas utiliza el mecanismo de conteo de referencias para decidir si debe destruir objetos que ya no se usen. Cuando tu aplicación ya no mantiene ninguna referencia a un objeto sabes que gambas lo eliminará, pero no sabes en qué momento.

Por otra parte, debido a que los componentes gb.qt4 y gb.gtk son básicamente envoltorios de las respectivas bibliotecas gráficas y gb.gui es básicamente una abstracción de esos dos componentes, cuando usas cualquier control gráfico (a menos que esté completamente escrito y dibujado mediante instrucciones de gambas) estas usando objetos que se crean y se destruyen fuera del alcance del intérprete de gambas. Esto implica que cuando tu aplicación ya no hace referencia a ninguno de los controles de un formulario, el momento de su eliminación de la memoria puede ser diferente del de otros objetos no gráficos que use ese formulario. No obstante, siempre los controles gráficos se pueden eliminar explícitamente.

Los problemas típicos que impiden la liberación de la memoria son que la aplicación manteniene al menos una referencia a un objeto y el programador no es consciente de ello o que el programador introdujo referencias circulares que hacen imposible la eliminación de un cierto objeto.

La conclusión es que para aprovechar la ventaja de no tener que administrar la memoria a mano como en lenguajes de nivel bajo/intermedio hay que aprenderse bien cómo funciona el mecanismo de conteo de referencias, ser consciente de que la creación y eliminación de objetos gráficos ocurre por fuera del alcance del intérprete, que hay que tener cuidado de no introducir en el programa variables que mantengan referencias innecesarias a objetos, y que hay que ser precavidos de no introducir referencias circulares.

Una vez que uno cumple con estas premisas, si se detectan problemas de memoria existe una probabilidad de un 99% (uso este número sólo para dar una idea) de que se trate de un problema de diseño o implementación más grueso en nuestra aplicación. Y sólo en última instancia deberíamos pensar que podría tratarse de un bug en gambas.

sebikul escribió: [Ver mensaje]

Volviendo al tema del diseño de una aplicación. Las aplicaciones gráficas en gambas, por diseño, suelen seguir el patrón MVC, solo que la Vista y el Controlador se "superponen".

El diseño de las aplicaciones gráficas en gambas NO sigue el patrón MVC, eso es responsabilidad del programador.

Sí es cierto que "vista" y "controlador" están acoplados en los formularios y eso un problema de todos los lenguajes que imitan la pobrísima implementación del modelo RAD de Visual Basic. Para desarrollar aplicaciones simples para el escritorio esto puede ser una ventaja si se usa correctamente, pero históricamente condujo a los programadores a escribir aplicaciones que acoplan fuertemente el modelo con la vista.

sebikul escribió: [Ver mensaje]

En la practica, lo mejor es abstraer todo código que maneje estructuras de datos (ya sea usando la memoria en el tiempo de ejecución o una base de datos) de el código que maneje la parte gráfica, donde suele haber interacción con el usuario.

Sí, por supuesto. Hay muchos mensajes anteriores en los que hablo sobre esto. Una cuestión esencial e inherente a la programación orientada a objetos es el grado fino de modularización que permite un diseño orientado a objetos correcto.

sebikul escribió: [Ver mensaje]

Para saber que es mas eficiente, si usar un Array o una Colección, depende como almacenes los datos.

¿Qué quisiste decir? Porque en cualquier caso, ya sea que uses un array o una colección, no tienes maneras diferentes de almacenar los datos, sino que para los arrays se almacenan de un modo y para las colecciones de otro.

sebikul escribió: [Ver mensaje]

En ambos casos, puede usar la IDE para perfilar la aplicación y saber exactamente cuanto tiempo tarda en ejecutar cada función.

Pero precisamente esto es lo que hay que evitar hacer a menos que sea estrictamente necesario. El rendimiento de la aplicación no debe ser una preocupación del programador a menos que el programa que está desarrollando tenga requerimientos explícitos respecto del rendimiento o bien que sin tener esos requerimientos existan funciones que potencialmente puedan hacer uso intensivo de la memoria, del tiempo de procesamiento o de acceso a dispositivos que puedan introducir retardos (como el acceso al disco, a una red LAN, etc).

Los programas se deben diseñar para que sea fácil modificarlos, que la corrección de errores no se transforme en una pesadilla y que la adición de características no implique un gran riesgo de introducir bugs. Para ello el código debe estar correctamente modularizado, sin código repetido, sus rutinas con alta cohesión y bajo acoplamiento, el código debe reflejar los conceptos del dominio del problema de manera clara y deben realizarse baterías de pruebas unitarias (y en sistemas no triviales también pruebas de integración).

La preocupación por el rendimiento debe tener lugar sólo despúes de que se tiene un programa funcionando con las características mencionadas antes y sólo si el rendimiento está planteado como un requerimiento. También el programador debe preocuparse por el rendimiento en aquellas partes del programa que, como dije antes, potencialmente podrían hacer un uso intensivo de la memoria, del procesador u otros dispositivos cuyo tiempo de acceso es variable y desconocido de antemano.

La optimización para el rendimiento generalmente introduce mayor complejidad en el código y por ello no debe realizarse prematuramente. Ya lo decía el Profesor Knuth hace como 40 años:

Premature optimization is the root of all evil (or at least most of it) in programming.

Saludos.

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

Speed Books: informática libre.