Ahora surge un nuevo problema. Tenemos un IntStack, que maneja enteros. Pero queremos una pila que maneje formas, o flotas de aviones, o plantas o cualquier otra cosa. Reinventar el código fuente cada vez no parece una aproximación muy inteligente con un lenguaje que propugna la reutilización. Debe haber un camino mejor.

Hay tres técnicas para reutilizar código en esta situación: el modo de C, presentado aquí como contraste; la aproximación de Smalltalk, que afectó de forma significativa a C++, y la aproximación de C++: los templates.

La solución de C. Por supuesto hay que escapar de la aproximación de C porque es desordenada y provoca errores, al mismo tiempo que no es nada elegante. En esta aproximación, se copia el código de una Stack y se hacen modificaciones a mano, introduciendo nuevos errores en el proceso. Esta no es una técnica muy productiva.

La solución de Smalltalk. Smalltalk (y Java siguiendo su ejemplo) optó por una solución simple y directa: Se quiere reutilizar código, pues utilicese la herencia. Para implementarlo, cada clase contenedora maneja elementos de una clase base genérica llamada Object (similar al ejemplo del final del capítulo 15). Pero debido a que la librería de Smalltalk es fundamental, no se puede crear una clase desde la nada. En su lugar, siempre hay que heredar de una clase existente. Se encuentra una clase lo más cercana posible a lo que se desea, se hereda de ella, y se hacen un par de cambios. Obviamente, esto es un beneficio porque minimiza el trabajo (y explica porque se pierde un montón de tiempo aprendiendo la librería antes de ser un programador efectivo en Smalltalk).

Pero también significa que todas las clases de Smalltalk acaban siendo parte de un único árbol de herencia. Hay que heredar de una rama de este árbol cuando se está creando una nueva clase. La mayoría del árbol ya esta allí (es la librería de clases de Smalltalk), y la raiz del árbol es una clase llamada Object - la misma clase que los contenedores de Smalltalk manejan.

Es un truco ingenioso porque significa que cada clase en la jerarquía de herencia de Smalltalk (y Java^[80]) se deriva de Object, por lo que cualquier clase puede ser almacenada en cualquier contenedor (incluyendo a los propios contenedores). Este tipo de jerarquía de árbol única basada en un tipo genérico fundamental (a menudo llamado Object, como también es el caso en Java) es conocido como "jerarquía basada en objectos". Se puede haber oido este témino y asumido que es un nuevo concepto fundamental de la POO, como el polimorfismo. Sin embargo, simplemente se refiere a la raíz de la jerarquía como Object (o algún témino similar) y a contenedores que almacenan Objects.

Debido a que la librería de clases de Smalltalk tenía mucha más experiencia e historia detrás de la que tenía C++, y porque los compiladores de C++ originales no tenían librerías de clases contenedoras, parecía una buena idea duplicar la librería de Smalltalk en C++. Esto se hizo como experimento con una de las primeras implementaciónes de C++^[81], y como representaba un significativo ahorro de código mucha gente empezo a usarlo. En el proceso de intentar usar las clases contenedoras, descubrieron un problema.

El problema es que en Smalltalk (y en la mayoría de los lenguajes de POO que yo conozco), todas las clases derivan automáticamente de la jerarquía única, pero esto no es cierto en C++. Se puede tener una magnifica jerarquía basada en objetos con sus clases contenedoras, pero entonces se compra un conjunto de clases de figuras, o de aviones de otro vendedor que no usa esa jerarquía. (Esto se debe a que usar una jerarquía supone sobrecarga, rechazada por los programadores de C). ¿Cómo se inserta un árbol de clases independientes en nuestra jerarquía? El problema se parece a lo siguiente:

Debido a que C++ suporta múltiples jerarquías independientes, la jerarquía basada en objetos de Smalltalk no funciona tan bien.

La solución parace obvia. Si se pueden tener múltiples jerarquías de herencia, entonces hay que ser capaces de heredar de más de una clase: La herencia múltiple resuelve el problema. Por lo que se puede hacer lo siguiente (un ejemplo similar se dió al final del Capítulo 15).

Ahora OShape tiene las características y el comportamiento de Shape, pero como también está derivado de Object puede ser insertado en el contenedor. La herencia extra dada a OCircle, OSquare, etc. es necesaria para que esas clases puedan hacer upcast hacia OShape y puedan mantener el comportamiento correcto. Se puede ver como las cosas se están volviendo confusas rápidamente.

Los vendedores de compiladores inventaron e incluyeron sus propias jerarquías y clases contenedoras, muchas de las cuales han sido reemplazadas desde entonces por versiones de templates. Se puede argumentar que la herencia múltiple es necesaria para resolver problemas de programación general, pero como se verá en el Volumen 2 de este libro es mejor evitar esta complejidad excepto en casos especiales.