1.3. La implementación oculta.

1.3. La implementación oculta

Es útil hacer una distinción entre creadores de clases y programadores clientes. Los primeros son aquellos que crean nuevos tipos de datos; y los últimos usan estos tipos de datos predefinidos en sus aplicaciones.

Así, el programador cliente acumula una caja de herramientas llena de clases, las que usará para un desarrollo rápido de sus aplicaciones. El objetivo de los creadores de clases es distinto, pues ellos buscan crear clases que expongan sólo lo necesario para el programador cliente, ocultando así lo demás.

Esto se hace a fin que el creador de clases pueda en un futuro realizar cambios en dichas clases sin preocuparse de las consecuencias. La parte oculta representa una sólida codificación en términos de optimización, pero resulta frágil en otro sentido, ya que puede fácilmente corromperse por un programador cliente descuidado o desinformado.

Ocultando la implementación se reducen estos errores de programación.

Un programador de avanzada puede crear librerías primarias, pero esto no quiere decir que los programadores clientes dejen de ser programadores; pues ellos, a su vez, pueden tomar estas librerías existentes para crear otra aún mayor.

En caso que los miembros de una clases estuvieran disponibles para cualquier (es decir, si no se impusiera restricciones), los programadores clientes podrían hacer lo que quisieran con dicha clase y no habría manera de limitarlos. Para evitar esto se usan controles de acceso, lo que permite salvaguardar la implementación (oculta).

Estos controles de acceso impiden al programador cliente tocar las partes que no debería (partes necesarias para los mecanismos internos de los tipos de datos, programación de bajo nivel), pero no se les limita el acceso a la interfaz, que es lo que ellos necesitan para resolver problemas. Esto es útil para los programadores clientes, pues así deben preocuparse menos por los procesos internos y centrarse específicamente en escribir soluciones para sus problemas.

Como ya se dijo anteriormente, esto permite además que los creadores de clases puedan hacer futuras modificaciones a sus tipos de datos abstractos (clases). Por ejemplo, podría haberse creado una clase de una manera sencilla, con un desarrollo poco complejo de código. ¿Qué ocurre si más tarde se requiere reescribirla para hacerla más rápida? Si la interfaz y la implementación están claramente separadas y protegidas, este proceso puede lograrse fácilmente y sólo se requeriría que el usuario vuelva a enlazar la aplicación (actualizarse respecto a los cambios).

En C++ existen tres palabras reservadas para poner límites en una clase: public, private y protected. El uso y significado de los mismos es un tanto sencillo. Estos son en sí especificadores de acceso, y determinan quién o quiénes pueden acceder a las definiciones que les siguen.

public: Significa que las definiciones posteriores están disponibles para cualquiera.

private: Nadie puede acceder a estas definiciones, excepto el creador del tipo. Actúa como una barrera entre el creador de la clase y los programadores clientes.

* Si alguien intenta acceder a un miembro privado, obtendrá un error al compilar.

protected: Actúa de manera muy similar a private, con la excepción de que las clases derivadas SÍ tienen acceso a miembros protegidos, pero a los privados no.

* La herencia se explicará en otro tema (es decir, dichas cuestiones de clases padres y clases derivadas).