|
4.10. Ejercicios | 5.2. Control de acceso en C++ |
|
Tabla de contenidos
Una librería C típica contiene una estructura y una serie de funciones que actúan sobre esa estructura. Hasta ahora ha visto cómo C++ toma funciones conceptualmente asociadas y las asocia literalmente
poniendo las declaraciones de las funciones dentro del ámbito de la estructura, cambiando la forma en que se invoca a las funciones desde las estructuras, eliminando el paso de la dirección de la estructura como primer parámetro, y añadiendo un nuevo tipo al programa (de ese modo no es necesario crear un typedef para la estructura).
Todo esto son mejoras: le ayudan a organizar su código haciéndolo más fácil de escribir y leer. Sin embargo, hay otros aspectos importantes a la hora de hacer que las librerías sean más sencillas en C++, especialmente los aspectos de seguridad y control. Este capítulo se centra en el tema de la frontera de las estructuras.
En toda relación es importante tener fronteras que todas las partes respeten. Cuando crea una librería, establece una relación con el programador cliente que la usa para crear un programa u otra librería.
En una estructura de C, como casi todo en C, no hay reglas. Los programadores cliente pueden hacer lo que quieran con esa estructura, y no hay forma de forzar un comportamiento particular. Por ejemplo, aunque vio en el capítulo anterior la importancia de las funciones llamadas initialize() y cleanup(), el programador cliente tiene la opción de no llamarlas. (En el capítulo siguiente verá una forma mejor de hacerlo.) Y aunque realmente prefiera que el programador cliente no manipule directamente algunos miembros de su estructura, en C no hay forma de evitarlo. Todo está expuesto a todo el mundo.
Hay dos razones para controlar el acceso a los miembros. La primera es no dejar que el programador cliente ponga las manos sobre herramientas que no debería tocar, herramientas que son necesarias para los entresijos del tipo de datos, pero que no forman parte de la interfaz que el programador cliente necesita para resolver sus problemas particulares. Esto es realmente una ventaja para los programadores cliente porque así pueden ver lo que es realmente importante para ellos e ignorar el resto.
La segunda razón para el control de acceso es permitir al diseñador de la librería cambiar su funcionamiento interno sin preocuparse de cómo afectará al programador cliente. En el ejemplo Stack del capítulo anterior, podría querer solicitar espacio de almacenamiento en grandes trozos, para conseguir mayor velocidad, en vez de crear un nuevo espacio cada vez que se añade un elemento. Si la interfaz y la implementación están claramente separadas y protegidas, puede hacerlo y el programador cliente sólo tendrá que volver a enlazar sus programas.
