1.3. La implementación oculta

Es útil distinguir entre los creadores de clases (aquellos que crean nuevos tipos de datos) y los programadores clientes [14] (los consumidores de clases que usan los tipos de datos en sus aplicaciones). El objetivo del programador cliente es acumular una caja de herramientas llena de clases que poder usar para un desarrollo rápido de aplicaciones. El objetivo del creador de clases es construir una clase que exponga sólo lo necesario para el programador cliente y mantenga todo lo demás oculto. ¿Por qué? Porque si está oculto, el programador cliente no puede usarlo, lo cual significa que el creador de clases puede cambiar la parte oculta sin preocuparse de las consecuencias sobre lo demás. La parte oculta suele representar las interioridades delicadas de un objeto que podría fácilmente corromperse por un programador cliente descuidado o desinformado, así que ocultando la implementación se reducen los errores de programación. No se debe abusar del concepto de implementación oculta.

En cualquier relación es importante poner límites que sean respetados por todas las partes involucradas. Cuando se crea una librería, se establece una relación con el programador cliente, quien también es programador, porque puede estar utilizando la librería para crear a su vez una librería mayor.

Si todos los miembros de una clase están disponibles para cualquiera, entonces el programador cliente puede hacer cualquier cosa con la clase y no hay forma de imponer las reglas. Incluso si quisiera que el programador cliente no manipulase directamente algunos de los miembros de su clase, sin control de acceso no hay forma de impedirlo. Nadie está a salvo.

Por eso la principal razón del control de acceso es impedir que el cliente toque las partes que no debería (partes que son necesarias para los mecanismos internos de los tipos de datos), pero no la parte de la interfaz que los usuarios necesitan para resolver sus problemas particulares. En realidad, ésto es un servicio para los usuarios porque pueden ver fácilmente lo qué es importante para ellos y qué pueden ignorar.

La segunda razón para el control de acceso es permitir al diseñador de la librería cambiar la implementación interna de la clase sin preocuparse de cómo afectará a los programadores clientes. Por ejemplo, podría implementar una clase particular de una manera sencilla para un desarrollo fácil, y más tarde descubrir que necesita reescribirla para hacerla más rápida. Si la interfaz y la implementación están claramente separadas y protegidas, puede lograrlo fácilmente y sólo requiere que el usuario vuelva a enlazar la aplicación.

C++ utiliza tres palabras reservadas explícitas para poner límites en una clase: public, private, y protected. Su uso y significado son bastante sencillos. Estos especificadores de acceso determinan quién puede usar las definiciones que siguen. public significa que las definiciones posteriores están disponibles para cualquiera. La palabra reservada private, por otro lado, significa que nadie puede acceder a estas definiciones excepto el creador del tipo, es decir, los métodos internos de la clase. private es una pared entre el creador de la clase y el programador cliente. Si alguien intenta acceder a un miembro privado, obtendrá un error al compilar. protected actúa como private, con la excepción de que las clases derivadas tienen acceso a miembros protegidos, pero no a los privados. La herencia se explicará en breve.



[14] Agradezco este término a mi amigo Scott Meyers.