Unidad 9. Procedimientos

9.1. Objetivos del tema.

Visto y nombrado los elementos de un programa y sus estructuras, así como la forma de representar las soluciones, ahora hemos de profundizar sobre el uso de los procedimientos, el paso de parámetros y sus características.

Los veremos desde el punto de vista genérico, sin entrar en lenguajes en concreto.

9.2. Introducción.

Un programa es una estructura más o menos compleja, en función del tamaño del mismo.

Pero el código que lo compone no puede estar todo en el Main del mismo, sería difícil de entender y de modificar, además de muy largo, por lo tanto conviene trocear.

Si recordamos el ejercicio del primer tema, ese es el camino, pequeños trozos de programa, fáciles de escribir y de modificar.

9.3. ¿Procedimientos o funciones?

En el peor de los casos, todo lo que se puede escribir en un procedimiento se puede resolver también con una función, o al revés, ¡técnicamente!, en la realidad no debe abordarse así.

El procedimiento nos va a permitir resolver la estructura de un programa, cuando nos dan los resultados del análisis de un problema, nos dan una estructura, y esa estructura se resuelve mediante el uso de procedimientos.

9.4. Procedimientos.

Siempre hemos de procurar crear procedimientos que sean cortos.

Se ha de intentar seguir la pauta de que un procedimiento no supere en mucho la capacidad de líneas de una pantalla o de una hoja de papel, no por ningún requisito técnico, si no por comodidad nuestra, lo cual no impide en absoluto que cuando nos interese lo superemos.

Un procedimiento debe de ser un espacio estanco, su forma de comunicación con los datos que hay en el exterior debe ser los que figuran en la línea de parámetros.

Cualquier otra forma de utilización, técnicamente puede ser correcta, y  de hecho habrá alguna vez que habrá que saltarse esa norma, consejo, pero a la larga se convierte en problemas.

Si creamos procedimientos sin dependencias del programa en el que se ubican, podemos cambiarlo de aplicación para aprovecharlo sin necesidad de reescribirlo, porque todos los datos que figuran en su interior tienen como origen su línea de parámetros, y no existe otra forma de comunicación. Así no pueden haber sorpresas.

Un procedimiento es un elemento de nuestro programa, este elemento puede recibir o no datos y devolver o no datos.

9.5. Ámbito de los procedimientos.

El ámbito de influencia de un procedimiento puede ser diverso, y su forma de utilizarse dependerá del lenguaje utilizado.

En éste ejemplo, el programa sabe que hay un procedimiento, A, pero desconoce lo que hay en su interior, eso es conocido solo por el procedimiento A.

El procedimiento A y B son conocidos por el programa principal, A conoce a B y B conoce a A, pero A no conoce a B1, ni B1 conoce a A.

9.6. Ambito de validez de las variables.

Con las variables sucede algo parecido, y además es muy importante que se usen adecuadamente, para evitar errores, aprovechar los recursos al máximo, y también para facilitar el modificación y comprensión del programa.

Las variables de nivel de programa, pueden ser utilizadas por los procedimientos en su interior, no es aconsejable.

Es conveniente utilizar el paso de variables, más que el uso de las globales, ya que eso le da independencia al procedimiento.

9.7. Paso de variables a los procedimientos.

El paso de variables a los procedimientos es el camino adecuado para su correcta utilización.

Para ellos hay que seguir unas normas, que son de lo más sencillas y absolutamente lógicas.

Si nosotros diseñamos un procedimiento, éste tendrá unas necesidades de datos.

Esos datos serán propios o externos, los propios no hay problema, pero los externos hemos de facilitárselos, para ello hay unas normas.

El envío y recepción han de realizarse en el mismo orden y con el mismo tipo de datos.

Si vemos el ejemplo, vemos que ambas coinciden en el color, digamos que sea el tipo, son del mismo tamaño, digamos que sea el dato que se envía.

El siguiente ejemplo vemos que no coinciden ni color, tipo, ni tamaño dato, ni el número de parámetros que se envían y reciben.

El nombre no tiene porque coincidir, pensemos que el mismo procedimiento puede utilizarse en varios programas, no tienen porque coincidir los nombres de las variables por eso, si no sería un problema bastante serio.

Actualmente hay lenguajes que permiten que haya variables de uso opcional en la línea de parámetros.

Pero eso es una excepción.

Aquí podemos ver como en el programa principal se envía dos variables a CALCULA, en este procedimiento se reciben en el mismo orden y con el mismo tipo.

A su vez luego desde CALCULA se llama a REPRESENTA y se le envía tres variables que se recogen igual.

9.8. Formas de paso de datos a los procedimientos.

Hay dos formas de pasar los datos a los procedimientos y funciones, por valor y por referencia.

El paso de datos por referencia, es lo que nos permite que un procedimiento sea independiente del programa que lo llama.

De esa forma podemos conseguir que un procedimiento trabaje con los datos de otro procedimiento o programa sin necesidad de que las variables se llamen igual.

El paso de datos por referencia a un procedimiento, nos da la posibilidad de poder modificar el valor de una variable pasada en el procedimiento, y que éste sea devuelto al programa principal o al procedimiento que lo ha llamado.

Cuando se pasa un dato por valor el dato es recibido por el procedimiento pero éste dato si se modifica en su interior no se recibe modificado en el lugar en el que se llama al procedimiento.

El paso de datos por valor a un procedimiento, nos da la posibilidad de poder enviar el dato de una variable a un procedimiento, y que la variable no pueda ser modificada en su contenido al finalizar la ejecución del procedimiento y devolverse el control al programa principal o al procedimiento que lo ha llamado.

9.9. Uso de variables en los procedimientos.

El uso de variables en los procedimientos y funciones no requiere de ningún requisito que se distinga del que se haga en el programa principal, ni por nombres, ni por ningún otro apartado que no sea lo que ha se ha expuesto en cuanto a tipos, ámbito y envío.

9.10. Públicos o privados.

No estamos hablando de empresas, si no de los procedimientos.

Los procedimientos pueden ser públicos o privados, dependerá del ámbito en el cual deseamos que sean utilizados.

Cuando el procedimiento se desea utilizar solo en el programa actual, y que no sea llamado desde otro programa, se declaran como privados, “Private”.

Cuando el procedimiento deseamos que sea algo de utilización genérica desde cualquier punto de la aplicación entonces lo declaramos como público, “Public”.

Normalmente los procedimientos públicos suelen agruparse en módulos fuera del programa, y agruparlos por temas, lo cual permite tener el código ordenado y fácilmente accesible.

Cuando desarrollamos una clase, el procedimiento o función que se declara como público, suele ser, se convierte en un método que el usuario puede utilizar en su objeto.