Necesidad de las Librerías | aprender-libre.com

LIBRERÍAS

NECESIDAD DE LAS LIBRERÍAS.

El uso de las librerías es absolutamente necesario en la construcción de aplicaciones de gestión.

El motivo fundamental es el importante ahorro de espacio de disco y de memoria que esto conlleva en la mayoría de los casos. Otro aspecto a tener en cuenta es el tiempo de programación que se gana si cada tarea que se repita, al menos una vez, a lo largo de una aplicación, se guarda en una librería y se la llama cada vez que la necesitemos, en vez de reprogramarla.

Muchas veces nos encontramos con la necesidad de realizar alguna tarea determinada y no disponemos de ninguna función en las librerías del compilador que la realice. Si se prevé esta tarea más veces, se compila, se añade a una de nuestras librerías y cada vez que la necesitemos, enlazamos nuestros programas con ella, sin preocuparnos de nada más. El enlazador se encargará de buscarla dentro de la librería y añadirla al ejecutable dejando las que no necesite para otra ocasión.

Si poseemos un conjunto de rutinas compiladas con las que enlazamos nuestros programas de forma habitual, estaremos añadiendo espacio innecesario a los ejecutables, a no ser que las utilicemos todas. El enlazador añade al ejecutable todo el código de los módulos compilados, los use o no, mientras que con las librerías sólo añade la parte del código que necesita.

Si poseyéramos todas nuestras rutinas compiladas por separado en módulos objeto y tuviésemos la precaución de enlazarlas una por una con nuestro programa cuando éste las necesite, estaríamos haciendo exactamente la misma función que hace el enlazador con una librería.

CONSTRUCCIÓN DE LIBRERÍAS.

Existen varios (programas) utilitarios en el mercado para la construcción de librerías, por ejemplo el programa LIB.EXE que viene junto a varios productos de Microsoft, o el TLIB de Borland que viene junto a Turbo C. El uso de éstos y las técnicas a seguir para la construcción de librerías son relativamente simples.

REGLAS BÁSICAS.

Para diseñar una librería no basta con conocer bien la mecánica de funcionamiento del programa constructor de librerías. Hace falta también seguir una serie de normas que optimicen el uso que más tarde se hará de nuestro programa. Algunas de estas normas básicas a observar son:

Hemos de procurar que las funciones estén bien documentadas, sobre todo en lo que al funcionamiento se refiere, para que cualquiera que utilice la librería no tenga dudas a la hora de usarlas.

· Hay que intentar planificar bien los módulos de manera que al enlazarlos con el resto de la aplicación no ocupen espacio de más. Llevando esto a una situación extrema, lo mejor es que cada función sea un módulo objeto distinto. Sin embargo, esta técnica hace crecer el tamaño de la librería y deja un gran número de objetos desperdigados por el disco duro, por lo que a veces es mejor pensar en módulos que agrupen a varias funciones. Esto último es adecuado:
- Cuando hay un grupo de funciones que se supone que si se utiliza una, se utilizarán las demás. Por ejemplo, si usamos funciones para controlar el ratón, está claro que al emplear una que detecte la pulsación del botón derecho también usaremos otra para detectar la pulsación del botón izquierdo.
- Cuando el código de un grupo de funciones sea muy pequeño y suponga un aumento despreciable de nuestro ejecutable.

· En caso de agrupar funciones en un mismo módulo objeto es aconsejable que traten de un mismo tema para mayor facilidad a la hora de localizarlas.

· No utilizar variables PRIVADAS o PUBLICAS, o sin declarar previamente, para optimizar espacio de ejecutable y memoria, y no interferir en las variables que declaren en sus aplicaciones los programadores que la usen.

· Declarar ESTÁTICAS las funciones auxiliares internas de la librería que no se usen para el resto de los programas.

· Hemos de procurar también que las funciones de nuestras librerías estén bien depuradas y pasen pruebas completamente rigurosas.

· Establecer un código de error que devuelvan las funciones cuando algo no vaya bien, por ejemplo – 1. Este código no tiene por que ser el mismo para todas, pero sí tiene que ser (dentro de lo posible) del mismo tipo de dato que el que devuelve cuando su ejecución es normal.

LAS LIBRERÍAS Y LOS GRUPOS DE TRABAJO.

Cuando trabajamos en equipo, y esto suele ser lo habitual, es lógico que cada programador no tenga que repetir el trabajo realizado por los otros. Por ello es bueno que exista para la empresa, el grupo de trabajo, el proyecto o al nivel que nos parezca oportuno, una librería común donde vayan a parar todas las rutinas de utilidad comunes. Es muy importante que la creación y el mantenimiento de esta librería se haga de un modo reglamentado para facilitar su buen uso y funcionamiento. Pensemos
en una empresa cualquiera (Chapuzas, S. A.) que se dedica al desarrollo de aplicaciones en Clipper.

Cuenta con 8 desarrolladores distribuidos en 3 proyectos. Existe un responsable cada proyecto así como uno de todo el grupo (Director Técnico). Un modelo de la organización para la gestión de una librería común podría regirse por las siguientes normas:

1. Debe haber una librería común CHAPUZAS.LIB para todos los desarrollos que la empresa lleve adelante. La responsabilidad última del uso y mantenimiento de esa librería es del Director Técnico. No obstante, deberá existir una Comisión de Control de Calidad encargada de la decisión de incorporación de funciones ya desarrolladas y del planteamiento de la necesidad de nuevas
funciones. Esta comisión se reunirá con carácter semanal. Uno de sus miembros ha de ser el desarrollador encargado de mantener físicamente la librería. En sus manos estará no solo la documentación de las funciones desarrolladas por otros sino también la de la creación de nuevas funciones a petición de la Comisión de Control de Calidad.

2. Cualquier función que se incorpore a la librería debe estar documentada y probada. La documentación debe constar de:
· Nombre de la función.
· Fecha de creación.
· Nombre del creador.
· Fecha de cada modificación.
· Nombre de cada modificador.
· Parámetros que usa con explicación detallada de los tipos, valores y funciones de cada uno de ellos.
· Lo devuelto en caso de error.
· Si maneja bases de datos, relación de las estructuras e índices.
· Si llama a otras funciones de la misma u otras librerías complementarias, la especificación de la misma.
· Breve descripción de la funcionalidad que realiza.
· Al menos un ejemplo de su uso.

3. Cuando cualquier equipo de trabajo necesite una rutina que considere necesaria para su aplicación y que tenga el carácter genérico como para ser incorporada a la librería, y no pueda esperar a la reunión de control de calidad, podrá desarrollarla por sí mismo e incorporarla a su código como un módulo OBJ. La comisión decidirá más tarde si:
· La función se incorpora a CHAPUZAS.LIB.
· La función no tiene interés general y, por tanto, no se incorpora a la librería aunque puede seguir formando parte de la aplicación.
· La función puede sustituirse por otra de la librería y, por tanto, el grupo de trabajo que la maneja debe modificar su código para eliminar la función por ellos desarrollada y adoptar la que corresponda de la librería.