Siempre ha habido clases

Volvemos al árido tema de las clases y de los objetos. A ver si podemos avanzar un poco más sin dormirnos.

Vimos en el capítulo anterior algunos de los aspectos más sencillos de los módulos de clases, y sus ventajas respecto a los módulos estándar.

Empezamos a construir un proyecto de gestión de amigos, empezando por un sistema "clásico", con formularios que se comunican por variables públicas, y como poco a poco hemos ido modificándolo hasta convertirlo en algo un poco (por ahora, poco) más robusto. Pero apenas nombramos algunas de las posibilidades de esta nueva herramienta de VB.

Hubo un aspecto que no sé si quedó muy claro en el capítulo anterior. De vez en cuando, hablábamos de "módulos de clases", en otros casos, de "instancias", en otros casos, de "referencias". Vamos a ver si aclaramos un poco el tema.

Un módulo de clases no es un objeto de VB, sino el esquema a base del cual se construirán otros: no es sino la receta con las que VB "cocinará" un objeto en tiempo de ejecución.

Una instancia es el objeto (pido disculpas ante los puristas) que VB construye, a partir de la clase, en tiempo de ejecución. La relación entre el módulo de clases y la instancia es la misma que entre el molde de una tarta y la tarta (el ejemplo está sacado del libro de Harold Davis "Secretos de Visual Basic": un libro de nivel intermedio que no es ninguna maravilla, pero se deja leer).

Pero una vez cocinada la tarta (creado el módulo de clases), tendremos que poder acceder a ella: supongamos que queremos comernos un trozo, pero la habitación está sin luz (ya sabéis que el funcionamiento de Windows es un poco oscuro): si cogemos un cuchillo, y empezamos a dar tajos, lo menos que nos puede pasar es que nos quedemos sin mano (y que se bloquee el sistema operativo). Para poder partirla, necesitamos saber dónde está "en el borde de la mesa que está a la derecha". La ubicación en memoria de la instancia es la referencia.

Lo del modelo, la instancia y la referencia no se aplica sólo a los módulos de clases: afecta a todo tipo de objetos de VB. Por ejemplo

En esa línea no se ha creado aún la instancia. Simplemente se ha reservado una posición en memoria para la referencia a ésta.

Ahora se "da la orden" de crear una copia en memoria del objeto (del formulario), aunque este todavía no se ha iniciado.

Ahora se ha dado a la copia del formulario (a la instancia) la orden de que se muestre (y como buen formulario, se carga solito en cuanto nos referimos a él). La orden no ha sido dada a Form1, sino a la nueva copia en memoria. Para localizarla, lo hacemos mediante su "dirección" (su referencia) que habíamos almacenado en la variable FLForm.

Ahora lo que hacemos es destruir (poner a cero) la variable que contenía la referencia de la instancia del formulario. Pero la instancia no se ha destruido. Sigue presente en memoria (y en la pantalla) hasta que reciba una orden específica (hasta que cerremos manualmente el formulario). Ahora bien, hemos "perdido" la dirección de la instancia y, en principio, ya no podemos localizarla (no es así realmente: VB almacena por su cuenta la referencia en la colección Forms, que podríamos localizar).

Es importante pues ver que el ciclo de vida de las instancias no tiene por qué ser el mismo que las referencias. Por una parte, podemos destruir la referencia mientras la instancia sigue cargada (como en el caso anterior). Y lo contrario: podríamos descargar el objeto mientras la referencia sigue existiendo:

En estos casos, al hacer nueva referencia al objeto, se crea una nueva instancia de éste (por eso a veces no se consigue cerrar aplicaciones mal diseñadas).

En un aspecto los formularios se comportan de una forma diferente a las clases: si tenemos un formulario (frmPrueba) y ponemos:

Lo que ocurre al pulsar es que directamente se accede a la copia actual de frmPrueba, y se imprime "Hola" (completamente diferente a lo que ocurría antes). Es como si hubiese una "referencia automática" a frmPrueba.

Esto se debe a que los formularios tienen una "instancia por defecto" a la que se accede si se usa su nombre. Es como si, por cada formulario que incluyésemos, hubiésemos puesto una línea (invisible) que pusiese:

Recordaréis del capítulo anterior las dos formas de declarar un módulo de clases. Ahora, frmPrueba es una instancia a una copia del formulario, pero podemos usarla también para crear nuevas copias:

En el ejemplo anterior, cuando cogemos un molde de la tarta frmPrueba, vemos que ya está lleno (con la instancia por defecto frmPrueba). Pero nadie nos obliga a usarla, sino que podemos crear nuevas copias (nuevas instancias) como vimos antes. Es más, suele ser ventajoso usar copias (ya que así evitamos el uso de una variable global, y restringimos el acceso a nuestras copias de los formularios). A cambio de una pequeña penalización en recursos, hacemos más sólida nuestra aplicación.

Esto se relaciona con un aspecto (que no es de las clases; es mucho más básico) que es el paso de los parámetros por valor y por referencia. Por ejemplo, vamos a tener una función que mostrará una cadena sin su última letra. Para ello tenemos un formulario con un TextBox, y este código:

Ahora la función se porta mejor, y "no mete la zarpa" dónde no debe.

La causa es que a las funciones no se les envía las variables, sino la dirección de memoria en la cual se encuentran. Cuando se pasa un parámetro por referencia, le indicamos a la función la ubicación de la variable, y le dejamos que haga con ella lo que quiera. Cuando pasamos un parámetro por valor, lo que hacemos es crear una copia temporal de la variable, e indicar a la función la dirección de la copia. La copia se destruirá cuando salga de ámbito, o sea, al acabar la función.

Por defecto, los procedimientos de VB reciben los parámetros por referencia. Este sistema puede ser marginalmente más rápido, ya que no se requiere la creación de copias locales, pero es inseguro (le damos al procedimiento la llave de casa).

En ocasiones desearemos enviar parámetros por referencia: por ejemplo, podemos querer una función que revise una cadena, quite los espacios, y devuelva por un lado la cadena sin los espacios, y por otra el número de espacios que había (por cierto, para hacer esto VB6 nos ahorrará mucho trabajo, con sus nuevas funciones como Replace). Para hacer eso, pasaremos a la función la cadena por referencia. La función modificará la cadena "directamente", y el valor devuelto será el número de espacios que había.

Pero ¿qué ocurre con los objetos? Habitualmente, lo que manejamos no son los objetos, sino referencias. Así, en este código:

Cada vez que pulsemos, obtendremos una ventana así:

A pesar de haber pasado el parámetro (el formulario) por valor, lo ha modificado. Se debe a que el parámetro enviado no es una copia del formulario, sino una copia de la referencia al formulario (y por tanto, el procedimiento sigue sabiendo donde encontrarlo). Si en lugar de pasarlo por valor, lo hacemos por referencia, parece que el efecto es el mismo. Pero las diferencias surgen cuando destruimos la referencia:

Seguirá funcionando, porque no se ha destruído la referencia almacenada, sino la copia local. Si sustituimos por ByRef:

Cuando vayamos a imprimir la línea "Otra", obtenemos un error "Se requiere un objeto": ahora no se ha enviado una copia de la referencia, sino la dirección de esta. Por eso ha podido destruirse.

Por tanto, un seguro contra errores y contra manipulaciones malintencionadas es enviar todos los parámetros por valor, incluyendo los objetos, salvo en los casos en los que necesitemos que la función manipule directamente el parámetro.

Una posibilidad de las clases, que no tienen los formularios, es la posibilidad de construir objetos complejos a base de otros objetos anteriores. Empezaremos por el principio, y veremos que ocurre con los TDUs.

Los Tipos Definidos por el Usuario (TDUs) pueden construirse a base de otros TDUs:

Así podremos construir una variable "a trozos", usando tipos anteriores, tipos definidos por el API, de alguna librería de tipos... Nos permite organizar mejor los datos que si todas las variables están en el "tipo base", organizando una especie de "jerarquía de tipos".

Además, los TDUs pueden incluir matrices, que pueden ser dinámicas. Por ejemplo, los amigos del ejemplo anterior pueden tener varias direcciones (la del trabajo, la del pueblo, la de sus padres), y varios teléfonos (también se han comprado móvil, que plaga):

Así podemos construir TDUs complejos que admitan cualquier tipo de datos, incluso relaciones complejas, listas de longitud variable, listas de elementos de distintos tipos... Pero este sistema de organización es ineficaz.

En primer lugar, los TDUs tipos complejos siguen siendo TDUs, con sus limitaciones: no pueden ser parámetros de procedimientos públicos (últimas noticias: en Visual Basic 6 sí pueden serlo: en las páginas del Guille hay más información), no filtran los datos introducidos sin un procedimiento externo (y si además algún elemento es Variant, no digamos), etc.

Pero las clases salen al quite: las podemos construir usando como componentes otras clases: así por ejemplo, podemos escribir una clase clsDireccion:

E incluirla en clsAmigo, usando un procedimiento Property Set:

También podría haber sido una variable pública:

Aunque ya sabéis que un procedimiento de propiedad nos da más control, como vimos en el capítulo anterior. Para acceder, lo haríamos siguiendo la cadena de clases (de referencias a las instancias de las clases, claro), con:

Los elementos de clsDireccion pueden ser también matrices. Pero no es tan sencillo implementarlo como en el caso de los TDUs. Si escribimos:

Nos dará un error: las matrices no pueden ser miembros públicos de un módulo de objeto (de un formulario o un módulo de clases). Pero podremos hacerlo con una matriz privada a la que accedamos mediante un procedimiento Property:

Este procedimiento es más complejo de lo esperado: no basta con asignar directamente el valor de la propiedad, ya que obtendríamos un error del tipo "Índice fuera de rango". Es preciso tener una rutina que redimensione la matriz.

Otro tanto puede hacerse en clsAmigo con clsDireccion: basta con poner:

En primer lugar, no hay ningún sistema de control que evite que se dejen espacios vacíos en la matriz: nos permitiría asignar:

Pero si accedemos a un "agujero"

Y nos daría una cadena vacía. Pero no es lo peor. Si ponemos:

conseguiremos un error. Por tanto, hemos de hacer aún más complejo el procedimiento de añadir datos: se debe revisar que no haya espacios vacíos en la matriz.

Hay otro problema que aún no habíamos abordado ¿y si nos peleamos con un amigo? Lo querremos borrar de la lista. Pero ¿cómo? Lo mismo, si queremos quitar una dirección, o lo que sea. No nos basta con eliminar la referencia:

Y lo llamaríamos así:

Vemos como este procedimiento devuelve DOS resultados: por un lado, la matriz (que se le envía por referencia y que, por tanto, puede modificar), y por otro, si ha funcionado.

Con esto hemos conseguido mantener la "coherencia" de la matriz, pero a costa de desordenarla: los índices de los elementos no son los primitivamente asignados. Y ni siquiera hemos acabado: hemos que proporcionar métodos que indiquen el tamaño de la matriz, claves para recuperar elementos, procedimientos para buscar duplicados… Vamos, un lío gordo.

Afortunadamente, Visual Basic proporciona una nueva herramienta que hace todo esto (y más) ella solita: las colecciones.

Las colecciones es una de las incorporaciones de VB4, que ha sido mejorada en VB5.

Si estuviésemos trabajando en C (cosa que, afortunadamente, no precisamos) tendríamos que decidir como guardar los datos: en arboles de elementos, en listas enlazadas, etc. Un sistema sencillo y eficaz es una lista enlazada, en la cual cada elemento guarda una referencia (un puntero) al siguiente. Y si queremos eliminar un elemento del medio, basta con "conectar" el anterior al siguiente.

Como hemos visto, las matrices no son capaces de hacerlo: son veloces, fáciles de usar, pero son muy rígidas, y para poder eliminar un elemento del centro necesitamos una matriz intermedia.

Para agregar una colección a nuestro proyecto, basta con escribir en él:

ó

Habitualmente, las colecciones se nombran con el plural del elemento contenido: una colección de Control se llama Controls, de Form Forms, y de elementos clsAmigo, Amigos (que raro: un sistema de nomenclatura lógico).

Las colecciones tienen tres métodos:

• El método Add, que añade elementos a la colección. Su sintaxis es:

El único parámetro requerido es el elemento que se añade, que puede ser de cualquier tipo (una variable, un objeto, lo que sea). Si no se suministra una clave, VB asignará una por su cuenta. Pero debe ser única: si se intenta añadir un elemento con una clave ya existente, se produce un error interceptable (que nos permite comprobar si un elemento ya estaba en la colección). Por defecto, los elementos se añaden al final, aunque podemos especificar el elemento anterior o posterior dónde queramos añadirlo (a costa de un descenso considerable en la eficiencia).

• El método Remove:

Donde índice puede ser la clave del elemento, o un valor numérico que indica la posición. Esto último es peligroso, ya que, a diferencia de las matrices, en una colección no conocemos la posición de sus elementos si no la comprobamos antes.

• El método Item

Que devuelve una referencia a un miembro de la colección. Índice puede ser un valor numérico (la posición) o la clave de un elemento. El método Item es el método por defecto de las colecciones, por lo que podemos poner, indiferentemente:

Teniendo en cuenta que las colecciones se numeran desde uno. Pero este sistema es demasiado rígido: si queremos eliminar un elemento de la matriz, podemos tener problemas, al cambiar la posición de los demás. Con el código:

Obtendríamos un error. Se podría evitar con un bucle inverso:

Insisto en que las colecciones, a diferencia de las matrices, no están ordenadas (sobre todo si ya hemos añadido y eliminado elementos): es conveniente hacer comprobaciones antes de manipular los elementos de la colección.

El proyecto PAmig2.vbp muestra como sustituir la matriz por una colección. Si se revisa el código, podemos ver que:

Después de todo lo que hemos visto, parece que las matrices son rudimentarias, y las colecciones una bendición del cielo ¿o no? Pues como siempre, depende de lo que queramos hacer.

Lo primero que vamos a hacer es una comparativa de velocidad. Para ello vamos a usar un proyecto sencillo, usando la función del API GetTickCount (podéis buscar en las páginas del Guille para ver cómo hacerlo).

En el proyecto vamos a comparar la velocidad de matrices y colecciones. Como no todas las matrices son iguales, ni todos los elementos, compararemos varios:

• Una matriz redimensionada al principio de Longs (el tipo "nativo" de Win32, y el más rápido, más que el Integer):

Para los vagos, por si no queréis escribir el código (que está en PTick.vbp), os he calculado los resultados (con mi ordenador: un P120 con 32 MB de RAM: no está mal, pero acepto subvenciones para pasar a un PII). De todas formas, tened en cuenta que los resultados pueden variar mucho, dependiendo del equipo, la memoria RAM, etc. (lo probé con un P233, y no había color).

Sin embargo, las matrices de objetos son más rápidas de lo esperado: al fin y al cabo no se guarda una copia del objeto, sino una referencia (que no es sino una especie de puntero: un número de 32 bits, Long).

En todos los casos, las colecciones se han quedado por detrás de las matrices. En algunos casos, las diferencias son muy significativas: con variables de "longitud fija": números, cadenas de longitud fija, referencias a objetos… Se comportan bastante peor con las de dimensión variable (String y Variant), dónde son sólo marginalmente más rápidas que las colecciones. De todas formas, hay que tener en cuenta que a pesar del gran número de iteraciones (30000), apenas tardan 1,7 segundos (la más lenta). Con un P233, no llegaban a 0,3 segundos.

Por tanto, tenemos una primera conclusión: matrices y colecciones son, en principio, suficientemente rápidas para nuestros fines. Pero si la velocidad es crítica, y para grandes números, son preferibles las matrices, sobre todo para referencias. Si se van a almacenar cadenas, u objetos "raros" (otras matrices, etc.), apenas hay diferencia. Pero, de todas formas, la velocidad no es criterio suficiente para decidirse.

Otra cuestión será la utilidad. En algunos casos, las matrices tendrán ventajas: cuando sólo se añadan elementos (y no se eliminen), cuando queramos estar seguros de la posición de cada uno. Si se van a extraer elementos, y no importa demasiado la pequeña pérdida de tiempo, lo nuestro serán las colecciones.

Para tareas sencillas (como un cálculo dentro de un procedimiento), es más lógico usar matrices, que son más sencillas de depurar y más rápidas de desarrollar. Tened en cuenta que es importante la velocidad de los programas, pero lo realmente caro es el tiempo del programador (a veces, es más barato actualizar el ordenador que actualizar el programa).

En resumen: de lo visto hasta ahora, las matrices son para tareas sencillitas, y las colecciones se tienen que enfrentar con las tareas "de verdad". Y eso, sin tener en cuenta la ventaja que vamos a ver ahora:

Si alguna vez os leéis los manuales de Visual Basic (cosa bastante recomendable, si es que los tenéis, claro) os habréis encontrado, en el apartado de las colecciones con unos ejemplo. Como los tenéis en el libro (y el código, en el CD-ROM) os los voy a ahorrar. Pero indican un problemilla que se nos había "olvidado" en el programa de "Gestión de amigos".

En el capítulo anterior habíamos hablado de la seguridad en las variables, y vimos como las variables, "a secas", pueden admitir datos absurdos (como amigos con una edad de –324,544 años). Y que en ocasiones, puede ser preferible el gasto de recursos de sustituir la variable por una clase que "filtre" los datos introducidos.

Pues con las colecciones, lo mismo. Vamos a mirar el ejemplo anterior, y vamos a añadirle una "bomba": añadimos un botón que añada a la colección una referencia a un control:

Esto se debe a una "desventaja" (o ventaja) de las colecciones: se puede guardar cualquier cosa (bueno, todo no; el pescado se estropea fuera de la nevera). Si declaramos una matriz:

Sólo podemos guardar datos del tipo declarado: o números, o referencias a instancias de la clase clsAmigos. Sin embargo, en la colección podríamos haber metido cualquier cosa, números, referencias a objetos, cadenas... Es casi como si hubiésemos declarado la matriz así:

Y metiésemos cualquier cosa.

Como siempre, podríamos haber incorporado filtros en el programa: por ejemplo, una instrucción como:

Que filtrase los datos a añadir, a leer… Pero tendríamos el mismo problema que vimos el capítulo anterior con las variables y los TDUs: necesitamos hacer comprobaciones en el código cada vez que fuésemos a usar la colección. Tendríamos que revisar el tipo de cada elemento; ni siquiera nos sería útil la propiedad Count (ya que si hay elementos equivocados, tampoco deberían contarse). Si vamos a tener una colección tan frágil ¿para qué complicarnos la vida? Una matriz, y a correr. Pero hay una solución:

Igual que podíamos tener una variable "envuelta" en una clase, con propiedades, valores por defecto, límites... podemos hacer lo mismo con una colección: envolverla dentro de un módulo de clases, que filtre las acciones que vayamos a realizar.

Para eso, debemos construir una clase que impida el acceso directo a la colección, pero que proporcione sus funcionalidades. Para ello, abrimos un nuevo módulo de clases (colAmigos), en el que ponemos una colección privada. Este módulo incluye los métodos y propiedades de la colección (Add, Item, Remove y Count), pero con diferencias:

• Los métodos Remove, Item y Count simplemente "transmiten" la orden a la colección:

En este caso, como puede verse, no se han incluido todas las propiedades de clsAmigo. Por una parte, aún no hemos implementado lo de la clase anidada Direccion. Por otra, la propiedad Edad es de sólo lectura, por lo que nos la hemos saltado.

Hay un nuevo procedimiento extraño:

Con todo esto, la clase-colección aún no está completa: son precisos algunos ajustes, pero que no podemos hacer desde la ventana de código. Necesitamos usar el cuadro de diálogo "Atributos del procedimiento", que está en "Herramientas". Pulsando "Avanzadas", podemos acceder a varias características especiales:

Necesitamos modificar dos procedimientos:

El proyecto PAmig3.vbp muestra las modificaciones realizadas. Como antes, no han variado clsAmigo ni frmAmigo. Sí se ha modificado frmGestion, pero ahora los métodos para añadir, etc., son mucho más sencillos. En las versiones anteriores, los elementos se creaban dentro de frmGestion. Ahora, la gestión (creación, comprobación, etc.) se ha trasladado a colAmigos, por lo que frmAmigos es mucho más sencillo.

Además, vamos a refinar todavía más el proyecto. Teníamos la colección "envuelta" dentro de una clase, con los mismos procedimientos que la colección. Pero nadie nos impide añadirle más. Así, en el proyecto PAmig4.vbp, podemos ver como hacer algunas mejoras.

En primer lugar, sería conveniente que la colección nos informase si se producen cambios en ella (si se añaden o si se quitan elementos). Aunque tiene la propiedad Count, esta sólo nos informa cuando la llamamos. Queremos algo que nos informe siempre. Para ello, añadimos un evento a colAmigos:

Que llamamos así (en Add y en Remove):

Para que frmGestion pueda recibir ese evento, es preciso que la declaración de colAmigos se haga con la palabra clave WithEvents:

Sin que se nos olvide iniciar la colección (en Form_Load). Ahora no puede hacerse con:

Ya que VB no nos lo permite. Ahora, en el editor de código, si editamos frmGestion, vemos que en la ventana de objetos hay disponible uno nuevo, el objeto Amigos, con un solo evento: Cambiotamaño.

Donde podemos escribir código.

Otra cosa que se puede echar en falta en una colección es algún método que permita eliminar todos los miembros de esta, más o menos la instrucción Erase de las matrices dinámicas, o el método Clear de los ListBox. Como nos gustaría tenerlo, lo añadimos:

Ahora podemos incluir un nuevo botón en frmGestion, que elimina todos los amigos de la lista. Como antes, no se han modificado (salvo por algún error detectado) frmAmigos, clsAmigos ni clsDireccion.

Si revisamos el proyecto, podemos ver como la estructura del mismo nos está quedando curiosa:

En el esquema puede verse como unos objetos "dependen" de otros. Tenemos un formulario principal (frmGestion), del cual depende frmAmigos (porque no puede presentarse independientemente, y se le llama desde un procedimiento interno). Se comunican mediante instancias de la clase clsAmigo (que a su vez, contiene la clase clsDireccion). Por otra parte, frmGestion almacena sus datos en colAmigos, que es una colecciónde instancias de clsAmigos (que contienen, a su vez instancias de clsDireccion).

Vemos como el proyecto está estructurado con una jerarquía de objetos, donde unos contienen a los otros (aunque algunos objetos están repetidos dentro del esquema).

Las clases son particularmente adecuadas para esta finalidad. Podemos construir con facilidad objetos complejos, de orden superior (con mucha clase), que se "dividen" en objetos más sencillos, más fáciles de usar, y más fácilmente reutilizables (como lo que hacen los ricos con la clase baja; aunque en VB no haya lucha de clases).

Por ejemplo, ahora vamos a construir un objeto "Coche" de esta forma:

La estructura está muy simplificada, claro. Pero vemos como la clase Coche contiene varios elementos: Chasis, Motor, Habitáculo, y la colección Accesorios (que no hemos desarrollado, para no cansar). Tiene además unas propiedades no relacionadas con los objetos contenidos, como pueden ser Nombre, Precio, Marca…

Cada uno de los objetos contenidos, a su ves, contiene otros: el motor está hecho de una colección de cilindros, tiene una transmisión, y tendrá propiedades como Nombre, Consumo… Y lo mismo: el objeto Cilindro está compuesto por una colección de Válvulas (de elementos Válvula), por un elemento Bujía, otro elemento Pistón (que contiene la colección Segmentos…).

Además, los elementos (con sus elementos dependientes) pueden ser usados en otros proyectos: se podrían tener otras instancias de Rueda (con valores diferentes de sus propiedades Marca, Tamaño, Presión…) en los objetos Camión, Bicicleta, Avión, CochecitoDeNiño…

Vemos cómo podemos convertir un proyecto desorganizado, una simple lista de archivos usados de cualquier forma (como se ven en el Explorador de Proyecto), en un proyecto estructurado, con dependencias precisas, que es algo más complejo de programar, pero mucho más sencillo de depurar, mantener y reutilizar. Pueden verse árboles de objetos de este tipo en los objetos de acceso a datos (podéis verlo mirando la ayuda sobre el motor de base de datos Jet).

Sin embargo, estos árboles de clases no son siempre convenientes, pues si son muy complejos pueden complicar más que ayudar. Como regla, si mantener un objeto complejo comienza a llevar demasiado trabajo, hay que fraccionarlo en un árbol. Y si tener una jerarquía de objetos sencillos se convierte en un dolor de cabeza, hay que juntarlos en uno solo.

Si me encargasen que diseñase la clase clsCoche, tal como la hemos visto, creo que me daría un soponcio. Me imagino escribiendo uno a uno los métodos y propiedades de cada clase, de cada colección, con sus parámetros, con sus atributos de procedimiento… Y al final, seguro que se me colaban tropecientos errores.

Gracias al Cielo, Don Guillermo Puertas es un alma caritativa que no puede dormir sin pensar en los pobres desarrolladores de VB. Y, pensando en ellos (y en los de C, y en los de Java, que también son de Dios) ha incluido en VB una herramienta que automatiza la construcción de clases y de estructuras complejas: la utilidad de construcción de clases (Class Builder Utility, en la lengua del imperio). Lo tenéis en el menú Add-Ins (y si no está, podéis agregarlo con el Add-In Manager).

Vamos a abrirlo. El proyecto PAmig4, visto con él, queda así:

En la ventana de la izquierda, podemos ver la estructura del proyecto, muy similar a la que vimos antes, con jerarquía. En la derecha tenemos las propiedades, métodos y eventos de la clase que seleccionemos. Además, la barra de herramientas (o el menú) nos permite añadir nuevos elementos. Los botones de la izquierda permiten añadir nuevas clases y nuevas colecciones, los del centro, nuevos métodos, eventos y propiedades.

Cuando añadimos cualquier cosa, se nos presentan diferentes opciones, dependiendo de lo añadido. Para ilustrarlo, vamos a construir la clase Coche que veíamos antes:

Para eso, iniciamos un nuevo proyecto (EXE estándar) y abrimos el asistente, que estará vacío. Añadimos una nueva clase, y se nos presenta esta ventana:

Como veíamos antes, Coche tiene varios componentes: Chasis, Motor, Habitáculo y Accesorios, y varias propiedades. Añadimos las propiedades:

Y, luego, añadimos los componentes. Para eso, seleccionando la clase Coche, pulsamos "Nueva clase", y añadimos las clases constituyentes.

Para añadir la colección Accesorios, pulsamos "Nueva colección" e indicamos los elementos contenidos (Accesorio: crea otra clase automáticamente).

Vamos creando todo el árbol, y en unos minutos tendremos ya:

Cuando cerramos el asistente, nos pregunta si actualizar el proyecto con los cambios. Si aceptamos, se crearán los módulos con las propiedades que hayamos indicado.

No son estas las únicas opciones del asistente. Podíamos haber creado clases basadas en otras clases ya existentes (una forma primitiva de herencia). También nos permite añadir código de control de errores, e instrucciones que escriben en la ventana de depuración los cambios que se produzcan. También permite arrastrar y soltar elementos (colecciones, clases, procedimientos, etcétera).

Por tanto, este asistente es una herramienta francamente útil, y es la que he usado para el desarrollo de las clases de los proyectos de ejemplo (¿o creíais que lo hacía a mano?). Pero, como buena herramienta de Microsoft, no es perfecta.

• Los nombres de las dichosas variables: no sé para qué tiene Microsoft un convenio de nomenclatura, si luego ellos mismos no lo siguen. El asistente deja algo así como:

Vamos, que con el asistente pueden construirse proyectos complejos, pero es necesario dar luego un buen repaso para que quede bien.

Aunque no sea una herramienta perfecta, os aconsejo que la uséis (y que aprendáis manoseándola). De todas formas, una advertencia: si alguien me presenta un proyecto con un objeto como Coche, le doy un capón. Puede quedar muy bonito como ejemplo, pero también me parece un ejemplo de cómo no hacer las cosas: un proyecto innecesariamente complejo que, salvo que vayamos a diseñar un coche ¿con Visual Basic? Sólo acaba siendo una fuente de problemas.

• Más arriba indica como hacer un método Remove (leed el artículo, no os voy a decir donde está).
• La propiedad Count sería algo así como:

Aunque espero que os penséis la razón del control de errores.

En la próxima entrega, hablaremos (supongo) de clases y programación orientada a objetos. Hasta la próxima.