El concepto de herencia constituye, la principal innovación del desarrollo orientado a objetos. Se trata de un concepto bastante simple e intuitivo que, de una manera informal, puede definirse como:
"el mecanismo que permite definir una clase de objetos tomando como base la definición de otra clase"
Una clase se define en términos de atributos y de métodos (u operaciones). Por tanto, otra forma de expresar la definición anterior seria la siguiente:
"herencia es el mecanismo que permite a una clase de objetos incorporar atributos y métodos de otra clase, añadiéndolos a los que ya posee".
En la terminología habitual, la clase que hereda las características de otra y la clase de partida reciben los calificativos de "subclase" y "superclase", respectivamente. De ahí que, en numerosas ocasiones, la relación de herencia aparezca también referenciada como "superclase/subclase".
Por otro lado, también suele ser muy habitual hablar en términos de "clase padre" y "clase hija", dado lo intuitivo de ambos términos.
Herencia simple contra múltiple
Hay dos grandes clases de la herencia de tipo: simple y múltiple. En términos generales, la herencia simple significa que cada subtipo tiene solamente un supertipo y sólo hereda propiedades de ese tipo; herencia múltiple significa que un subtipo puede tener cualquier cantidad de supertipos y hereda propiedades de todos ellos. Obviamente, el primero es un caso especial del segundo.
Herencia escalar, de tupia y de relación
De manera clara, la herencia tiene implicaciones para los valores que no son escalares y también para los escalares, ya que a final de cuentas, esos valores que no son escalares están construidos con valores escalares. Por supuesto, tiene implicaciones en particular para los valores de tupia y de relación. Sin embargo, aun la herencia escalar es bastante complicada (de nuevo, de manera sorprendente.
Herencia estructural contra la herencia de comportamiento
Recuerde que los valores escalares pueden tener una estructura o representación interna (física) de una complejidad cualquiera; por ejemplo, las elipses y los círculos pueden ser legítimamente considerados como valores escalares en circunstancias adecuadas (como ya sabemos), aunque su estructura interna pueda ser bastante compleja. Sin embargo, esa estructura
interna siempre está oculta ante el usuario. De esto se deduce que cuando hablamos de herencia (al menos en lo que se refiere a nuestro modelo) no queremos decir herencia de estructura, ¡ya que desde el punto de vista del usuario no hay estructura a heredar! En otras palabras, estamos interesados en lo que a veces se llama herencia de comportamiento y no en la herencia estructural (donde "comportamiento" se refiere a los operadores; aunque le
recordamos que al menos en nuestro modelo también se heredan las restricciones).
Un ejemplo de Herencia de tipos:
Supóngase que se dispone de la siguiente definición de tipos para las personas:
create type Persona (nombre varchar(20), direccion varchar(20))
Puede que se desee guardar en la base de datos más información sobre las personas que son estudiantes y sobre las que sean profesores. Dado que los estudiantes y los profesores también son personas, se puede utilizar la herencia para definir los tipos de estudiante y profesor.
create type Estudiante under Persona (curso varchar(20), departamento varchar(20)) create type Profesor under Persona (sueldo integer, departamento varchar(20))
Tanto Estudiante como Profesor heredan los atributos de Persona, es decir, nombre y dirección. Estudiante y Profesor se denominan subtipos de Persona y ésta, a su vez, es un supertipo de Estudiante y de Profesor.
Ejemplo de Herencia en Tablas:
Las subtablas se corresponden con la noción del modelo E-R de la especialización y la generalización. Por ejemplo, supóngase que se define la tabla personas de la manera siguiente:
create table persona of Persona
Se pueden definir entonces las tablas estudiantes y profesores como subtablas de persona:
create table estudiantes of Estudiante under persona create table profesores of Profesor under persona
Los tipos de las subtablas deben ser subtipos del tipo de la tabla padre.
Por tanto, cada atributo presente en persona debe estar también presente en las subtablas. Además, cuando se declaran estudiantes y profesores como subtablas de persona, cada tupla presente es estudiantes o profesores también están presentes implícitamente en persona. Así, si una consulta usa la tabla persona, encontrará no sólo las tuplas insertadas directamente en la tabla, sino también en las tuplas insertadas en sus subtablas estudiantes y profesores. Sin embargo, sólo se puede acceder a los atributos que están presentes en persona.
POLIMORFISMO
Otro concepto interesante, con importantes aportaciones en áreas tales como la flexibilidad o la legibilidad del software, es el de polimorfismo. Tras este término, un tanto oscuro, subyace una idea bastante simple. En su más amplia expresión, el polimorfismo puede definirse como:
"el mecanismo que permite definir e Invocar funciones idénticas en denominación e interfaz, pero con implementaron diferente".
Esta definición introduce un aspecto muy importante del polimorfismo: la asociación, o vínculo, entre cada llamada a una de estas funciones polimorfismo y la implementación concreta finalmente invocada. Cuando este vinculo puede establecerse en tiempo de compilación, se suele hablar de vinculación estática (static binding). Por contra, cuando la implementación a emplear, puede determinarse en tiempo de ejecución, el término empleado es el de vinculación dinámica (dynamic binding).
