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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 182 — #220
✐
Capítulo 5. Ocultar la implementación
}* head;
public:
void initialize();
void push(void* dat);
void* peek();
void* pop();
void cleanup();
};
#endif // STACK2_H ///:~
Como antes, la implementación no cambia por lo que no la repetimos aquí. El
programa de prueba es también idéntico. La única cosa que ha cambiado es la robustez
del interfaz de la clase. El valor real del control de acceso es prevenirle de
traspasar las fronteras durante el desarrollo. De hecho, el compilador es el único que
conoce los niveles de protección de los miembros de la clase. No hay información
sobre el control de acceso añadida en el nombre del miembro que llega al enlazador.
Todas las comprobaciones sobre protección son hechas por el compilador; han
desaparecido al llegar a la ejecución.
Dese cuenta de que la interfaz presentada al programador cliente es ahora realmente
la de una pila. Sucede que esta implementada como una lista enlazada, pero
usted puede cambiar esto sin afectar a la forma en que los programas cliente interactúan
con ella, o (más importante aun) sin afectar a una sola linea de su código.
5.6. Manejo de clases
El control de acceso en C++ le permite separar la interfaz de la implementación,
pero la ocultación de la implementación es solo parcial. El compilador debe ver aún
la declaración de todas las partes del objeto para poder crearlo y manipularlo correctamente.
Podría imaginar un lenguaje de programación que requiriese solo la interfaz
publica del objeto y permitiese que la implementación privada permaneciese
oculta, pero C++ realiza comparación de tipos estáticamente (en tiempo de compilación)
tanto como es posible. Esto significa que se dará cuenta lo antes posible de si
hay un error. También significa que su programa será más eficiente. De todas formas,
la inclusión de la implementación privada tiene dos efectos: la implementación es visible
aunque no se pueda acceder a ella fácilmente, y puede causar recompilaciones
innecesarias.
5.6.1. Ocultar la implementación
Algunos proyectos no pueden permitirse tener visible su implementación al publico.
Puede dejar a la vista información estratégica en un fichero de cabecera de una
librería que la compañía no quiere dejar disponible a los competidores. Puede estar
trabajando en un sistema donde la seguridad sea clave - un algoritmo de encriptación,
por ejemplo - y no quiere dejar ninguna pista en un archivo de cabecera que
pueda ayudar a la gente a romper el código. O puede que su librería se encuentre en
un ambiente «hostil», donde el programador accederá a los componentes privados
de todas formas, usando punteros y conversiones. En todas estas situaciones, es de
gran valor tener la estructura real compilada dentro de un fichero de implementación
mejor que a la vista en un archivo de cabecera.
182
✐
✐
✐
✐