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 programador cliente sólo a enlazar de nuevo sus programas.