TEMA 7: Relaciones entre objetos. Herencia, polimorfismo, enlace dinámico.

Herencia

• Las relaciones de herencia suelen representar situaciones donde las clases base son o representan conceptos más generales mientras que las derivadas son más específicas.
• Ya sabemos que modelan una relación de parecido entre elementos del mundo real: es un.
• Aunque, si el lenguaje lo permite, podemos modelar otro tipo de relaciones con ellas.
• Cuando una clase base es abstracta y además no tiene datos se dice que es un interfaz.

C++ y las relaciones de herencia.

• C++ permite etiquetar la relación de herencia entre dos clases.

• Una clase puede heredar de otra de forma publica, privada y/o protegida.

  class Derived : public Base {};
  class Derived : private Base {};
  class Derived : protected Base {};
  

C++ y las relaciones de herencia.

• IMPORTANTE:

  Herencia pública :

  Lo público en la clase base es público y lo protegido en la clase base es protegido en la clase derivada. Lo privado de una clase siempre es privado de esa clase. Representa relaciones es un.

  Herencia privada :

  Lo público y protegido en la clase base es privado en la clase derivada. Simula relaciones de composición o agregación.

C++ y las relaciones de herencia.

Herencia protegida :

Lo público y protegido en la clase base es protegido en la clase derivada. Simula relaciones de composición o agregación.

C++ y las relaciones de herencia.

Herencia multiple de clases.

• Sirve para representar que una nueva clase tiene cierto tipo de relación con otras clases de forma simultánea.

• En C++ basta con separar por comas las clases base de las que heredamos:

  class Derived : public Base1, protected Base2, private Base3 {};
  

Herencia multiple de clases.

• Ya sabemos que la herencia múltiple de clases puede plantearnos el problema de la herencia repetida.

• Para resolverlo podemos (en ocasiones) transformar ciertas clases en interfaces, o emplear la herencia virtual:

  class Storable {...};
  class Transmitter: public virtual Storable {...};
  class Receiver: public virtual Storable {...};
  class Radio: public Transmitter, public Receiver {...};
  

Reutilización de métodos en clases derivadas.

• Un método heredado en una clase derivada se puede:

  • quedar como se hereda:

    class B : {
    public:
       virtual void m () {...}
    };
    class D : public B {...};
    D d;
    d.m();                          // B::m
    

Reutilización de métodos en clases derivadas.

• reescribir completamente:

  class B : {
  public:
     virtual void m () {...}
  };
  class D : public B {
  public:
    void m () { ... };
    // C++11 admite override, p.e.
    void m () { ... } override;
  ...
  };
  D d;
  d.m();                          // D::m
  

• Para más información sobre override consulta su documentación.

Reutilización de métodos en clases derivadas.

• Un método heredado en una clase derivada se puede:

  • refinar:

    class B : {
    public:
       virtual void m () {...}
    };
    class D : public B {
    public:
       void m () {
          ...;
          B::m ();                  // Heredado
          ...;
       };
    ...
    };
    D d;
    d.m();                          // D::m
    

Constructores y destructor en clases derivadas.

• En cualquier constructor de una clase derivada podemos invocar el constructor que queramos de sus clases base.

• Si no lo hacemos, entonces se invoca automáticamente el constructor por defecto. Recuerda que si no lo creamos y nuestra clase no tiene declarado de forma explícita ningún constructor entonces el compilador genera uno por nosotros.
• Desde C++11 en adelante podemos pedir explícitamente que cree o se elimine el constructor por defecto.

Constructores y destructor en clases derivadas.

• La forma de invocar un constructor de una clase base desde uno de una clase derivada es:

  class B : {
  public:
    B (int b) {...}
  };
  class D : public B {
  public:
     D (int n, char c) : B(n), _c(c) , ac(n) { ... }; // Fase de iniciacion.
  private:
     char _c;
     AnotherClass ac;
  };
  

Constructores y destructor en clases derivadas.

• Importante: A los constructores y destructor les afecta la zona de visibilidad de la clase bajo la cual se declaran! Tenlo en cuenta.

• Importante: El destructor de una clase base debería tener enlace dinámico: virtual ~T(). Piensa por qué puede ser apropiado hacerlo.
• Los constructores de clases derivadas se invocan en el orden de la herencia, primero los de clases base luego los de objetos contenidos por valor y finalmente el de la clase derivada.

Constructores y destructor en clases derivadas.

• El orden de invocación de destructores es justo a la inversa.
• Un destructor no se suele invocar directamente, pero si es necesario se puede hacer.

class A {
  public:
    ~A() { std::cout << "Destructor de A\n"; }
};

int main() {
  A a;
  a.~A();  // Invocación manual
  //Al terminar el ámbito, se vuelve a invocar.
}

Composición y agregación

• Aunque son dos relaciones similares, en el fondo son diferentes.

Composición

• El objeto contenedor es dueño del ámbito de vida del objeto contenido:

  class Robot {
  ...
     Robot () : mySensor ("temp-sensor") {}  // Fase de iniciación
  private:
     Sensor mySensor;             // 'mySensor' es un Objeto completo
  };
  
  Robot* r2d2 = new Robot;        // Creamos a r2d2
  ...
  delete r2d2;                    // 'mySensor' desaparece con r2d2
  

Agregación

• El objeto contenedor sólo tiene una referencia al objeto contenido, no controla su ámbito de vida:

  class Robot {
  public:
     Robot () { aSensor = nullptr; }
     void setSensor (Sensor* s) { aSensor = s; }
  ...
  private:
     Sensor* aSensor;             // 'aSensor' es una referencia
  };
  
  Robot* c3po = new Robot;
  Sensor lightSensor;
  
  c3po.setSensor (&lightSensor);
  ...
  delete c3po;
  ...
  {
     Robot anotherRobot;
     anotherRobot.setSensor (&lightSensor);
     ...
  }
  
  if (lightSensor.isLightOn()) ...
  

Relaciones de uso.

• Las relaciones de uso entre objetos son aquellas que no son ni de herencia ni de composición y en las que intervienen al menos dos objetos, uno los cuales solicita a otro u otros que lleven a cabo una o varias acciones.
• Estos otros objetos pueden estar accesibles como:

  • variables globales:

    TempSensor aTempSensor;
    ...
    class Robot {
       void doSomeThing () {
          float temp = aTempSensor.readTemp();
       }
    }
    

• Estos otros objetos pueden estar accesibles como:

  • variables locales:

    class Robot {
       void doSomeThing () {
          TempSensor aTempSensor;
          float temp = aTempSensor.readTemp();
       }
    }
    

  • parámetros de un método:

    class Robot {
       void doSomeThing (TempSensor aTempSensor) {
          float temp = aTempSensor.readTemp();
       }
    }
    

Polimorfismo

• Es un término nuevo aplicado a la tarea de programar que aparece con la relación de herencia que modela la relación es un.

• Lo podemos ver como el hecho de que tenemos un interfaz común para objetos de tipos diferentes, pero que mantienen entre ellos una relación de tipo es un.

• Nos evita el uso de sentencias switch en base a un campo tipo.

class Shape {                       |   class Circle : public Shape {
public:                             |   public:
   virtual float area () = 0;       |      virtual float area () {...}
   virtual void draw () = 0;        |      virtual void draw () {}
   ...                              |      ...
}                                   |   }

class Rectangle : public Shape {    |   class Triangle : public Shape {
public:                             |   public:
   virtual float area () {...}      |      virtual float area () {...}
   virtual void draw () {}          |      virtual void draw () {}
   ...                              |      ...
}                                   |   }

...
Shape* aos[MAXSHAPES];
for (int i = 0; i < MAXSHAPES; i++) {
  int st = rand(1..4);          // numero aleatorio: 1=circulo,
                                // 2=rectangulo, 3=triangulo
  if (st == 1) aos[i] = new Circle;
  if (st == 2) aos[i] = new Rectangle;
  if (st == 3) aos[i] = new Triangle;
}
...
for (int i = 0; i < MAXSHAPES; i++) aos[i]->draw(); // No switch was harmed here!

• En este vídeo puedes ver el ejemplo de las figuras geométricas de forma pŕactica.

Principio de sustitución de Liskov

• Principio definido por Bárbara Liskov en 1994.

  Dados dos tipos S y T, si S es un subtipo de T (p.e. por herencia) entonces en un programa que haga uso de ambos, cualquier objeto de tipo T puede ser sustituído por uno de tipo S sin que se vean alteradas ningunas de las propiedades deseables del programa, tales como corrección, cometido, etc…

Enlace dinámico.

• Algunos autores también lo llaman enlace tardío (late binding), y en algunas traducciones puedes encontrar referencias a él como despacho dinámico.
• De temas anteriores ya sabemos lo que esto implica: La elección del código a ejecutar (método) en respuesta a un mensaje enviado a un objeto se hace en tiempo de ejecución y no de compilación.

Enlace dinámico.

• Solemos encontrarnos con esta situación cuando tenemos clases relacionadas mediante herencia (jerarquía de clases) las cuales proporcionan implementaciones diferentes para el mismo mensaje.
• En C++ los métodos con enlace dinámico son aquellos que van anotados con la palabra reservada virtual. De lo contrario el enlace por defecto de métodos en C++ es estático (tiempo de compilación), esto es así por razones de eficiencia del código en tiempo de ejecución.

Enlace dinámico de métodos en C++

Para que en C++ un método tenga enlace dinámico tenemos que tener en cuenta lo siguiente:

• El método en la clase base debe ser declarado virtual, y además…
• Debe tener exactamente la misma signatura en la clase derivada, con una excepción, se permiten tipos covariantes en el tipo de resultado del método en clases derivadas.

Enlace dinámico de métodos en C++

• Dados dos tipos B y D, se consideran tipos covariantes si D deriva directa o indirectamente de B, por tanto los métodos virtuales definidos en clases derivadas pueden tener un tipo de resultado distinto del método en la clase base si este tipo es derivado del tipo de dato que devuelve el método en la clase base.

Un ejemplo de enlace dinámico y covarianza de tipos en C++

class Shape {
  public:
    Shape () { std::cout << "Shape const.\n";}
    virtual ~Shape () { std::cout << "Shape Dest.\n";}

    virtual Shape* clone () = 0; // Fíjate en la clase derivada...
  };

  class Line : public Shape {
  public:
    Line () { std::cout << "Line const.\n";}
    ~Line () { std::cout << "Line Dest.\n";}

    Line* clone () { return new Line; } // Line deriva de Shape!
  };

¿Es necesario el modificador virtual en las clases derivadas?

• No, no lo es. Lo podemos ver en el ejemplo anterior.

  El método Line::clone() no lo tiene. El compilador ya lo sabe.

¿Es necesario el modificador virtual en las clases derivadas?

• C++11 introduce el modificador override (opcional) y nos permite detectar errores de compilación relacionados con el enlace dinámico:

  class A {
  public:
      virtual void foo();         // Enlace dinámico
      void bar();
  };
  
  class B : public A {
  public:
      void foo() const override; // Error: B::foo does not override A::foo
                                 // (signature mismatch)
      void foo() override;       // OK: B::foo overrides A::foo
      void bar() override;       // Error: A::bar is not virtual
  };
  

C++, enlace dinámico y destructores.

• El destructor de una clase es un método más…
• Que puede estar especializado en clases derivadas.
• Es por eso que en la clase base debería estar declarado como virtual…
• De lo contrario si destruimos un objeto de una clase derivada mediante un puntero a la clase base, sólo se invocará el destructor de la clase base y no el de la derivada.

Enlace dinámico de métodos y otros LOO

• El caso de C++ es uno de los pocos LOO que han optado por el enlace estático de métodos por defecto.
• En general, los LOO eligen por defecto el enlace dinámico de métodos (Java, C#, D, SmallTalk, etc…).

Enlace dinámico de métodos y otros LOO

• En estos otros LOO tenemos que indicar explícitamente que queremos que un método tenga enlace estático para no incurrir en la penalización que ya conocemos respecto a la doble indirección.

  Casi todos ellos suelen emplear el modificador final:

  // Java
  class Shape {
    public Shape () {...}
    public final void store () {...}     // enlace estático
  }
  

• Esto, además, implica que Shape.store() no puede ser redefinido en clases derivadas.

C++11 tiene modificador final para métodos y clases…

• Si, lo tiene.

• Símplemente dice que una función virtual no puede ser redefinida en una clase derivada o que no podemos derivar de una clase, mira:

  class A {
      virtual void foo() final;   // A::foo is final
      void bar() final;           // Error: non-virtual
                                  // function cannot be final
  };
  
  class B final : A {            // B is final
      void foo();                 // Error: foo cannot be overridden
                                  // as it's final in A
  };
  
  class C : B {                  // Error: B is final
  };
  

UML

• En el paradigma de POO existen formas de representar la estructura de clases y relaciones entre objetos de un diseño de manera independiente de la sintáxis concreta de un lenguaje de programación.

• Se conocen como lenguajes de modelado. El más empleado hoy en día es UML: Unified Modeling Language.
• Estos lenguajes nos permiten representar nuestro diseño orientado a objetos de manera gráfica, fácil de entender y que permite cierto tipo de automatizaciones.

• Un ejemplo muy sencillo sobre como representar clases y las relaciones de herencia, composición y agregación entre ellas:

Aclaraciones

• Este contenido no es la bibliografía completa de la asignatura, por lo tanto debes estudiar, aclarar y ampliar los conceptos que en ellas encuentres empleando los enlaces web y bibliografía recomendada que puedes consultar en la página web de la ficha de la asignatura y en la web propia de la asignatura.