Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

HERENCIA MLTIPLE EN JAVA

Oscar A. Len, Mariana Brachetta, Julio Monetti

Ctedra Paradigmas de Programacin
Departamento de Ingeniera en Sistemas de Informacin
Universidad Tecnolgica Nacional Facultad Regional Mendoza.
Coronel Rodrguez 273. 5500 Mendoza. www.frm.utn.edu.ar
Tel. 0261 4239596. oleon@frm.utn.edu.ar, mbrachetta@mendoza.edu.ar,
monetti@uncu.edu.ar

RESUMEN
En el artculo se comentan algunos aspectos de la utilizacin de relaciones de herencia mltiple, para el
desarrollo de software orientado a objetos. En particular se analiza una alternativa de implementacin de
este tipo de relaciones en el lenguaje Java. Dado que el mismo no permite implementar relaciones de
herencia mltiple en forma directa, las mismas se "simulan" mediante la utilizacin de interfaces, lo cual
se muestra a travs de un ejemplo, en el cual se discuten algunos aspectos de la implementacin. Tambin
se analiza el modo de soportar caractersticas como reusabilidad, polimorfismo, redefinicin de mtodos y
definiciones de mtodos forwarding, y se comentan algunas de las desventajas que presenta.

PALABRAS CLAVE
Herencia Mltiple. Lenguaje Java. Programacin Orientada a Objetos. Patrones.

11

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

INTRODUCCIN
Uno de los objetivos de la programacin orientada a objetos, es incrementar la
productividad en el desarrollo de software. Uno de los modos de lograr sto, es
mediante la reutilizacin de cdigo existente, para lo cual las relaciones de herencia son
uno de los medios ms utilizados.
Un buen diseo del esquema de relaciones de herencia resulta crtico, ya que si el
mismo est bien hecho facilitar la reutilizacin de cdigo, permitiendo mantener al
mismo tiempo el control del desarrollo del software. Por otra parte, un mal diseo, har
que la reutilizacin de cdigo se vea dificultada o impedida.
El diseo del lenguaje Java, imposibilita pensar el diseo de un programa aplicando
herencia mltiple (Eckel, 2000), como se podra hacer por ejemplo en C++. Java
permite nicamente una forma cercana al concepto de herencia mltiple, a travs de la
implementacin de interfaces. Esta restriccin de los diseadores del lenguaje, les ha
permitido simplificar la implementacin del compilador.
Cuando se utilizan lenguajes como C++, frecuentemente se hace un uso indebido de las
relaciones de herencia mltiple, lo cual hace que el mismo pierda integridad. En Java
esto no ocurre, ya que no ofrece soporte para este tipo de relaciones.
Si bien las relaciones de herencia mltiple, aparecen muy pocas veces frente a las de
herencia simple, ambos esquemas tienen ventajas y desventajas (Ghan Bir Singh, 1995);
en ocasiones se presentan situaciones en las cuales la utilizacin de relaciones de
herencia mltiple resulta conveniente.

HERENCIA MLTIPLE
Dentro de los lenguajes O.O. (orientados a objetos) existen algunos que soportan
herencia mltiple, como C++ (Stroustrup, 2000) y Eiffel (Meyer, 2001); en cambio
otros no, como en el caso de Smalltalk y Java. Si bien, la mayora de las situaciones
pueden resolverse sin recurrir a herencia mltiple, en algunos casos es conveniente
contar con esta caracterstica, a fin de lograr una mejor implementacin de la aplicacin.
Desde el punto de vista del diseo de un lenguaje, soportar herencia mltiple complica
la tarea de implementacin, ya que hay que prever cmo resolver situaciones como la
que se muestra en la Figura 1, mediante el diagrama UML de relaciones de herencia
mltiple entre las clases A, B y C (Fowler y Scott 2000). Cuando un objeto de clase C
tiene que acceder al atributo p, el lenguaje debe tener algn medio de discriminar a cul
atributo p se quiere referir, si al de la clase A o la B.

Figura 1: Herencia mltiple

12

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

Una situacin ms complicada es la que se muestra en la Figura 2, que presenta un caso

de herencia mltiple con un ancestro comn. El atributo p se hereda a travs de dos
ramas diferentes, entonces un objeto D podra tener dos copias del mismo atributo, una
la que hereda por la rama de B y otra por la de C. Lenguajes como C++ y Eiffel, tienen
diferentes abordajes para resolver situaciones como estas.

Figura 2: Herencia mltiple con ancestro comn

Los problemas antes mencionados, son una consecuencia del modo de construir un
objeto de una clase que hereda de otra. Una relacin de herencia, como por ejemplo
entre las clases C y D, implica que un objeto de la clase D es una forma particular de C.
Este tipo de vnculos entre clases, se describen con expresiones como extiende o es
un, que dan la idea de que un objeto D es una forma de objeto C. As, un objeto D va a
tener una parte que va a ser C, pero tambin una parte que ser B, lo cual plantea
algunos problemas de ambigedad que se deben resolver (Stroustrup 2000).
Los problemas comentados pueden aumentar, cuando se fuerza el concepto de herencia
(Seidewitz, 1996). Por ejemplo, en ocasiones se establecen relaciones de herencia
mltiple slo para reusar en una clase, capacidades de otras. Esto hace que el diseo de
la aplicacin sea difcil de comprender y de mantener, ya que no existe un vnculo
natural entre clases. Una relacin de herencia mltiple debe surgir sin forzarla.
Un ejemplo de libro de texto de esta situacin, se muestra en la Figura 3, donde se
define una clase auxiliar de docencia alumno (AuxDocAlu). Esta nueva entidad es
una extensin de la clase Alumno, pero tambin cumple funciones relacionadas con la
docencia, por lo que le corresponden atributos como Asignatura (en la que trabaja).
Ante esto, se puede caer en la tentacin de definir una relacin de herencia mltiple con
la clase Docente, pero con esto tambin hereda atributos y mtodos, que no le son
propios como Sueldo, u otros que se duplican, como el Legajo, todo lo cual complica la
implementacin.

13

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

Figura 3: Herencia mltiple forzada

En el caso de tener que programar con un lenguaje O.O. que no soporte herencia
mltiple, se tienen dos alternativas, o re-disear la aplicacin de modo tal que no
aparezcan este tipo de relaciones, o se deben "simular".

HERENCIA EN JAVA
En vista de las situaciones de herencia mltiple descriptas anteriormente que se pueden
presentar, parece razonable que el diseador de un lenguaje prefiera no tener que
implementar dicho mecanismo. Pero en el caso de Java, tambin existe un motivo que
va ms all de la conveniencia para el implementador del lenguaje. La ejecucin de un
programa Java se basa en un intrprete de un seudocdigo de mquina (byte-code). Esta
caracterstica es lo que ha permitido la independencia de la plataforma sobre la que se
ejecuta una aplicacin Java.
El uso de bibliotecas de clases en Java es un mecanismo muy flexible, dado que la
mayora de los enlaces se resuelven durante el tiempo de ejecucin. As, se puede
recompilar una clase, sin necesidad de hacer lo mismo con su subclase, y la aplicacin
va a continuar ejecutndose en forma correcta. Esta caracterstica podra dar lugar a
errores, en el caso de que existiera herencia mltiple. En el ejemplo de la Figura 1, si
suponemos que en A agregamos un mtodo cuya cabecera coincide con la de un mtodo
ya definido en B, y si desde C se activa el mtodo, ahora no alcanza con recompilar A,
sino que ser necesario resolver la ambigedad en la activacin del mtodo desde C y
recompilar tambin esta ltima clase.

SIMULACIN DE HERENCIA MLTIPLE

Analicemos un caso de implementacin en Java, basado en el esquema propuesto en la
Figura 4, donde suponemos la existencia de un mtodo denominado algo(), que es
redefinido para cada clase con distintos comportamientos.

14

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

Figura 4: Esquema de herencia mltiple con un mtodo redefinido en ambas ramas

class A {
public void algo() {
System.out.println("A");
}
}
class B extends A {
public void algo() {
super.algo();
System.out.println("B");
}
public void hace() {
System.out.println("Hace");
}
}
class C extends A {
public void algo() {
super.algo();
System.out.println("C");
}
public void otro() {
System.out.println("Otro");
}
}
class D extends C, B {
public void algo() {
super.hace();
super.otro();
System.out.println("D");
}
}
Listado 1: Implementacin del esquema de la Figura 4

15

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

En el modelo aparecen tres conceptos fuertemente vinculados a las relaciones de

herencia: reusabilidad, redefinicin de mtodos y polimorfismo (Booch, 1994). El
primero de ellos debido a la reutilizacin del mtodo algo() de A, desde B y C. El
segundo aparece al redefinir la implementacin de algo() a travs de toda la jerarqua de
clases, en B, C y D. El tercero aparecer, al activar el mtodo antes mencionado para
algn objeto de la jerarqua, en cuyo caso se debe lanzar la ejecucin del mtodo que
corresponda al objeto referenciado en ese momento, de acuerdo al comportamiento que
se espera por la aplicacin del concepto de polimorfismo (Cardelli y Wegner, 1985).
La idea de polimorfismo se basa en ocultar bajo una interface comn, diferentes
implementaciones de mtodos. As si durante la ejecucin del programa en distintos
instantes de tiempo, por ejemplo con una variable del tipo A, se refieren objetos de las
clases A, B, C, D, para enviarles el mensaje algo(); en cada caso se activar la
implementacin del mtodo algo(), correspondiente a la clase a la que pertenece el
objeto referenciado por la variable en ese momento. Esto se debe a que la
implementacin del concepto de polimorfismo, se fundamenta en establecer vnculos
dinmicos entre la llamada a un mtodo y su respectiva implementacin. As la
resolucin sobre cul implementacin utilizar, se demora hasta el momento de la
ejecucin, cuando se conoce la clase a la que pertenece el objeto referenciado durante el
envo de un mensaje.
Retomando el planteo realizado en el cdigo correspondiente a la Figura 4; el problema
es que Java no provee medios para implementar herencia mltiple, por esto el cdigo
provoca un error durante el proceso de compilacin, en el enunciado donde se indica
que D hereda de C y B; como consecuencia de esto las activaciones super.otro() y
super.hace() no son posibles.
La alternativa a lo anterior es simular el esquema de herencia mltiple propuesto. Esta
implementacin, tiene que realizarse respetando las caractersticas de reusabilidad,
redefinicin de mtodos y polimorfismo, que presenta el modelo originalmente
propuesto. Para llevar adelante esto, se aprovecha una caracterstica de Java, que
permite heredar en forma simultnea de una clase y una interface. Estrictamente, no
se trata de herencia mltiple, sino de heredar de una clase e implementar una o ms
interfaces, en las cuales por definicin todos los atributos son constantes y todos los
mtodos son abstractos (Cornell y Horstmann, 1996).

Simulacin de herencia mltiple

Mediante el uso de interfaces, en algunos casos, se pueden simular relaciones de
herencia mltiple en Java. En la Figura 5, se muestra cmo quedara el nuevo esquema
de relaciones entre clases.

16

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

Figura 5: Esquema de relaciones que implementan herencia mltiple en Java

En el diseo del modelo se han incorporado nuevos elementos. Aparece una interface
iB, que es implementada por las clases B y D. As, la relacin de herencia entre las clase
D y B del modelo original, se ha reemplazado por la implementacin de la interface
comn iB, por parte de las clases B y D, en tanto que D mantiene la relacin de herencia
con C, simulndose de esta forma la herencia mltiple de las clases B y C. Adems, se
ha incorporado una relacin de agregacin bidireccional entre las clases B y D. La
necesidad de esto ltimo resultar evidente ms adelante, por lo que en la primera
versin que se muestra, slo aparece implementada como una relacin unidireccional.
class A {
public void algo() {
System.out.println("A");
}
}
interface iB {
public void algo();
public void hace();
}
class B extends A implements iB {
public void algo() {
super.algo();
System.out.println("B");
}
public void hace() {
System.out.println("Hace");
}
}
class C extends A {
public void algo() {
super.algo();
System.out.println("C");
}

17

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

public void otro() {

System.out.println("Otro");
}
}
class D extends C implements iB {
private iB objBase = new B();
public void algo() {
objBase.hace();
super.otro();
System.out.println("D");
}
public void hace() {
objBase.hace();
}
}
Listado 2: Implementacin del esquema de la Figura 5
El comportamiento polimrfico se debe preservar. Para garantizar esto en la interface iB
se han declarado todos los mtodos de acceso pblico que tiene B. Esto es necesario
para que el compilador genere cdigo para enlazar dinmicamente la implementacin de
dichos mtodos en las respectivas clases, con una llamada en el momento de la
ejecucin. De no hacerlo, enunciados como los siguientes provocan error:
iB obj;
if (alguna condicin) obj = new B();
else obj = new D();
obj.algo();
Si el mtodo algo() no se declara en la interface, como una variable del tipo iB puede
referenciar objetos de las clases B o D, la activacin del mtodo algo() sera invlida, ya
que el compilador no conocera el smbolo algo. En cambio, al declararlo en la
interface, an cuando no se conoce la clase de objeto referenciada por la variable obj, el
cdigo se puede compilar. El enlace de la llamada al mtodo con su implementacin,
queda demorado hasta el momento de la ejecucin.
Por la relacin de herencia entre C y D, cualquier modificacin en los mtodos de C, se
propaga a D. La implementacin debe producir el mismo efecto respecto de la relacin
de herencia entre B y D. Por otra parte, al declarar en la interface iB el mtodo hace(),
se obliga a tener que implementarlo en la clase D.
El concepto de herencia implica que un objeto de una clase derivada, es una forma ms
especializada de un objeto de la clase base de la cual deriva; esto hace que crear un
objeto de una subclase, requiera la creacin de un objeto (subobjeto) perteneciente a la
superclase (Budd, 2002). En Java esa es la funcin del mtodo super(), cuando se activa
desde el constructor de una clase derivada. Por lo tanto desde el punto de vista de
cmo es construido un objeto de una clase derivada, se puede decir que est
compuesto por un objeto (subobjeto) de la clase de la cual deriva. Es interesante
observar que esto es as, an cuando la clase de la cual se hereda sea abstracta. Por lo
tanto la restriccin de no poder crear objetos de una clase abstracta, no es aplicable para
la construccin del subojeto que forma parte de un objeto de una clase derivada.
18

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

Esto ltimo, produce una restriccin en el modelo presentado, ya que no es posible

simular herencia mltiple a partir de clases abstractas, debido a que no sera posible
crear el subobjeto necesario para simular el mecanismo de herencia.
En la clase D, el enunciado super.otro() del mtodo algo(), lo que hace es activar el
mtodo otro() correspondiente al objBase de la clase C, de la cual hereda. En la nueva
implementacin se debe simular un efecto similar, para la otra rama de herencia. Esto se
logra declarando el atributo privado objBase del tipo B, al cual se le asigna una
referencia a un objeto B, que se utilizar para sustituir la activacin super.hace() por
objBase.hace().
En el caso que D y B tuvieran constructores parametrizados para inicializar los objetos
que se creen, la asignacin a objBase de la referencia al objeto B, debera realizarse en
el constructor de D para simular el mismo efecto.
La declaracin de hace() en la interface iB, obliga a implementar el mtodo en D. En el
modelo original, como D no tiene definido el mtodo hace(), un objeto del tipo D
directamente heredara la implementacin desde B. La implementacin del mtodo
hace() en D, simula ese comportamiento. Esta es una tcnica de diseo de patrones
estructurales, conocida como Adaptadores o Wrappers (envolturas) (Gamma et al,
1995).
Estos patrones sirven para modificar el comportamiento de otra clase, operando como
una cobertura sobre la clase encapsulada, que es la que en realidad realiza el trabajo.
Los mismos pueden extender el comportamiento, modificar la interface o restringir el
acceso a una clase. En general su funcin es hacer de intermediarios entre dos interfaces
incompatibles, traduciendo las llamadas entre ellas.
Finalmente como se puede observar, cualquier modificacin que se realice en los
mtodos de la clase B, se va a propagar a la clase derivada D. La redefinicin de
mtodos y el comportamiento polimrfico, se garantizan a travs de la definicin de la
interface iB, y del uso de referencias a esta ltima, en lugar de hacerlo con B.

Implementacin de forwarding
Supongamos que el cdigo de las clases C y D, ha sido modificado como se muestra a
continuacin, donde aparece un mtodo denominado nuevo(), que es implementado en
la clase C y luego es redefinido en D.
class C extends A {
public void algo() {
System.out.println("C");
super.algo();
}
public void otro() {
System.out.println("Otro");
nuevo();
}
public void nuevo() {
System.out.println("C: nuevo");

19

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

}
}
class D extends C implements iB {
private iB objBase = new B();
public void algo() {
System.out.println("D");
objBase.hace();
super.otro();
}
public void hace() {
objBase.hace();
}
public void nuevo() {
System.out.println("D: nuevo");
}
}
Listado 3: Implementacin de forwarding
Para los siguientes enunciados, cuando se procese la llamada incluida en otro() de C, la
implementacin del mtodo nuevo() que se activar ser la correspondiente a la clase D
y no a C. Este comportamiento se debe a que el objeto que inici la secuencia de
activaciones de mtodos pertenece a la clase D, y lo que se hace es activar un mtodo
que se encuentra definido ms adelante (forwarding) en la jerarqua de herencia.
C obj = new D();
obj.algo();
En el caso de plantearse una situacin semejante para la clase B, se debe simular el
mismo comportamiento. Esto se puede hacer manteniendo una referencia inversa desde
el objeto base de la clase B al objeto derivado del tipo D. Entonces del cdigo de
ambas clases, para una situacin similar a la antes descripta sera el siguiente, con lo
cual se completa el esquema presentado en la Figura 5.
interface iB {
public void algo();
public void hace();
public void nuevo();
}
class B extends A implements iB {
private iB objDeriv;
public B() {
super();
objDeriv = this;
}
public B(D obj) {
super();
objDeriv = obj;
}
public void algo() {
super.algo();
20

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

System.out.println("B");
}
public void hace() {
System.out.println("Hace");
objDeriv.nuevo();
}
public void nuevo() {
System.out.println("B: tres");
}
}
class D extends C implements iB {
private iB objBase;
public D() {
super();
objBase = new B(this);
}
public void algo() {
objBase.hace();
super.otro();
System.out.println("D");
}
public void hace() {
objBase.hace();
}
public void nuevo() {
System.out.println("D: tres");
}
}
Listado 4: Implementacin final del esquema de la Figura 5
Las referencias cruzadas se implementan, agregando el atributo objDeriv en B, que
debe ser del tipo iB porque se necesitar referenciar con esta variable objetos del tipo B
o D. Adems se han incorporando dos constructores, que establecen los vnculos en el
momento de crear un objeto D. El constructor sin parmetros en B, se requiere por
haber sobrecargado los constructores de la clase, pero adems se necesita para
inicializar el atributo objDeriv con la referencia a s mismo, cuando la creacin de un
objeto B no es consecuencia de la creacin de un objeto de la clase D. El mtodo
nuevo() adems de en las clases, debe ser declarado en la interface.
La activacin del mtodo nuevo() en B, se hace utilizando la variable objDeriv, que
referencia un objeto B o D, segn corresponda.

Reutilizacin
Si se quiere crear una clase que herede de D, reutilizando mtodos definidos en la
jerarqua de herencia, la tarea no resulta complicada.
Por ejemplo una clase X que hereda de D, en la cual se redefinen los mtodos algo() y
nuevo(). Tambin se define un mtodo propio(), que reutiliza los mtodos hace() y
otro(), de las clases B y C respectivamente.

21

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

class X extends D {
public void propio(){
System.out.println("Propio");
hace();
otro();
}
public void algo() {
propio();
}
public void nuevo() {
System.out.println("X: nuevo");
}
}
A continuacin se declara una variable del tipo A, que por ser la raz de la jerarqua
de herencia, posibilita referenciar objetos pertenecientes a cualquiera de las subclases.
Luego se crea un objeto del tipo X y se activa el mtodo algo().
A p = new X();
p.algo();
En este caso la salida es la siguiente:
Propio
Hace
X: nuevo
// Salida de la llamada a nuevo(), desde hace() en B
Otro
X: nuevo
Como se puede observar los comportamientos del programa, debidos a la aplicacin de
conceptos como reutilizacin, polimorfismo y forwarding, son los que cabe esperar.

CONCLUSIONES
Se ha analizado una alternativa de implementacin de herencia mltiple, en un lenguaje
como Java, que no soporta este tipo de relaciones. Para esto se utiliza una interface,
cuya funcin es proveer el acceso a la clase de la cual se pretende heredar en forma
mltiple. Varios aspectos del tema abordado, se enmarcan dentro de lo que se denomina
patrones de diseo, donde aparecen patrones como agente, agente virtual, interfaz de
negocios.
A fin de ilustrar las modificaciones que se deben realizar sobre el modelo original, para
simular herencia mltiple, se ha utilizado el nombre iB para la interface. Sin embargo,
en una situacin de aplicacin del esquema propuesto, se debera denominar a la clase
B, por ejemplo como implB (implementacin de B) y a la interface iB con el nombre B,
a fin de mantener la coherencia en los nombres de identificadores del modelo original.
Si bien la implementacin requiere de varios artificios de codificacin, la complejidad
de esta queda oculta para quien reutiliza la clase D, por lo tanto su tarea no se ve
complicada, obteniendo como resultado el comportamiento esperable, de un lenguaje
que soporte esquemas de herencia mltiple.

22

Proyecto Leonardo

Ao 4 Volumen 3 Nmero 1 Octubre de 2008

ISSN 1668-7523

No obstante lo anterior, la implementacin presentada es una solucin de compromiso a

un problema para el que el lenguaje Java, no provee enunciados que permitan tratarlo en
forma directa. Esto hace que lo propuesto tenga algunas desventajas:
La clase de la cual se hereda no puede ser abstracta, ya que no sera posible crear el
subobjeto, que ha permitido mantener el vnculo con el objeto de la clase de la cual se
deriva, como se explica al comentar la implementacin del Listado 2.
En el modelo original de la Figura 4, si se quiere manipular un objeto del tipo D,
utilizando una referencia del tipo B, esto se puede hacer, y se aplica el comportamiento
polimrfico. En cambio en el modelo de la Figura 5, esto se debe hacer empleando una
referencia a la interface iB, para mantener las caractersticas de polimorfismo.
El esquema de relaciones propuesto presenta dificultades para el crecimiento. Por
ejemplo, para crear una nueva clase que herede de C y B, se debe modificar la clase B,
para agregar el constructor que permite mantener la relacin inversa con la nueva clase.
Este tipo de acoplamiento en un diseo, es una prctica que va en contra de los
principios de la metodologa orientada a objetos.
Tampoco se ha analizado, cmo se debera abordar el problema del acceso a
miembros protegidos (atributos o mtodos), si estos aparecieran en el modelo original.

REFERENCIAS
Booch, G. (1994). Object Oriented Analysis and Design: With Applications. Addisson
Wesley
Budd, T. (2002). Introduction to Object-Oriented Programming, 3/E. Addison-Wesley
Cardelli, L. Wegner, P. (1985). On Understanding Types, Data Abstractions, and
Polymorphism. Computing Surveys. 17.4: 471-523
Cornell, G. Horstmann, C. S. (1996). Core Java. The Sun Press. Prentice Hall
Eckel, B. (2000). Thinking in Java. Prentice Hall.
Fowler, M. Scott, K. (2000). UML Distilled: A Brief Guide to the Standard Object
Modeling Language 2/E. Addisson Wesley
Gamma, E. Helm, R. Johnson, R. Vlissides, J. (1995). Design Patterns: Elements of
Reusable Object-Oriented Software. Addisson Wesley
Ghan Bir Singh. (1995). Rensselaer Polytechnic Institute at HGC. Single Versus
Multiple Inheritance in Object Oriented Programming. Hartford, CT, USA
Meyer, B. (2001). An Eiffel Tutorial, ISE Technical Report TR-EI-66/TU. Interactive
Software Engineering Inc.
Seidewitz, E. (1996). Controlling Inheritance. Journal of Object Oriented Programming.
8.8: 36-42
Stroustrup, B. (2000). The C++ Programming Language. Addisson Wesley

23