Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 171 — #209
✐
5: Ocultar la implementación
Una librería C típica contiene una estructura y una serie de funciones
que actúan sobre esa estructura. Hasta ahora hemos visto cómo
C++ toma funciones conceptualmente asociadas y las asocia literalmente
poniendo la declaración de la función dentro del dominio 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 ayuda 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.
5.1. Establecer los límites
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. (Veremos una forma mejor de hacerlo en
el capítulo siguiente.) Incluso si realmente prefiere que el programador cliente no
manipule directamente algunos miembros de su estructura, en C no hay forma de
evitarlo. Todo está expuesto al 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 definido, pero no
parte del 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 como afectara 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 un elemento es añadido. Si la interfaz y la implementación
están claramente separadas y protegidas, puede hacerlo y forzar al
171
✐
✐
✐
✐