Imaginemos que una empresa, Caos Informático S.L. (en abreviatura C.I.), necesita manejar objetos de tipo genérico "string". Lo más inmediato sería usar de forma directa la clase "RWCString", pero esto plantea sus propios problemas: si Rogue Wave cambia el nombre de sus clases en futuras versiones (como ha ocurrido con la nombrada, que antes se denominaba "RWString"), o si deseamos cambiar de librería, nos encontraremos que nuestro código cliente de tales clases deberá ser modificado. Pero esto no es lógico. ¿Cuál es, pues, la solución? Sencilla: debemos crear una clase "nuestra" que sirva de interfaz entre nuestras aplicaciones y las librerías elegidas: class CIString : private RWCString { public: // constructores // aquí se explicita el constructor // adecuado de la clase base CIString() : RWCString() {} CIString( const char* cs ) : RWCString( cs ) {} // ... // seguidamente se hacen accesibles desde objetos de // nuestra clase CIString diversas funciones de RWCString RWCString::operator==; RWCString::hash; // ... // aquí se cambia el interfaz de alfunas // funciones de RWCString void cambiaAMinusculas() { RWCString::toLower(); } // ... };
La verdad es que la clase "RWCString" consta de un número elevado de métodos propios (¡sesenta y cinco!), incluyendo indexación, subcadenas, etc. Hemos creado en un momento, pues, una clase para el manejo de cadenas totalmente pulida, y además, por la derivación privada, hemos establecido una barrera que impide el acceso al código de la librería. Pero, un momento: después de una larga serie de capítulos de introducción a C++, el avieso lector podría plantear: ¿y si, en lugar de derivación pública, planteamos una derivación protegida? O también: ¿y si trocamos la derivación por "layering", incluyendo un objeto de tipo "RWCString" en la sección privada de nuestra clase "CIString"? Pues que yo sólo podría decir: ¡Bravo, amigo lector! ¡Se nota que ya empieza a pensar antes de codificar! Veamos las dos cuestiones: en cuanto a la primera, la derivación protegida significa que el interfaz de la clase "RWCString" y de sus correspondientes clases bases será accesible en el protocolo de las clases derivadas de nuestra clase "CIString", de forma que otros componentes del equipo de desarrollo podrían establecer subinterfaces de uso de la librería, pero esto no parece, en nuestro caso, muy aconsejable; la otra posibilidad, inteligente lector, se refiere a una cuestión que Tom Cargill denomina "herencia innecesaria": ya que no vamos a favorecernos de C++/OOP: UN ENFOQUE PRÁCTICO
Página 113/297