Practical Object Oriented Design in Ruby – Herencia

Herencia, aunque el capítulo se llama como adquirir comportamiento a partir de la herencia, sencillamente es herencia en programación orientada a objetos.

Herencia nos da una manera de definir dos objetos que tienen una relación, tal que cuando el primero recibe un mensaje que no entiende, automáticamente reenvia o delega el mensaje al segundo objeto.

Para definir esta relación entre dos objetos, se crean subclases que básicamente son clases que requieren una verdadera especialización de la super clase o clase padre.

Sin duda es un concepto que la mayoria manejamos de una o de otra manera sin embargo en este capítulo se hace la pregunta de cuando debemos reconocer que utilizar herencia es adecuado.

En otras palabras es necesario saber cuando tenemos la necesidad de compartir código a partir de una herencia, considerando que proveera un sistema automático de entrega o delegación de mensajes entre objetos no necesariamente entendidos.

En mi opinión la mejor manera de explicar un concepto es poniendo un ejemplo y como programar no es la excepción aqui va:

Como pueden observar esta clase Taco, podria fácilmente utilizarse para otros tipos de tacos, de pescado, barbacoa, sesos, de cabeza, de tripita etc, sin embargo cada uno de estos tacos requieren de una o más propiedades de las que se describen en el método “que_lleva”.

Inmediatamente vemos que en el método que_lleva ponemos un “IF” con el tipo para distinguir cuando otro tipo de taco es creado desde nuestra clase, lo cual nos permite también ver el primer error de diseño. El cual es muy claro al tratar de agregar otro tipo de taco con otras caracteristicas, sabores, salsas.

Importante es también señalar que en ruby particularmente, todas las clases heredan de la clase “object” independientemente si se define en la clase su herencia o no.

Por lo regular el problema con la clase tacos es un ejemplo simple que nos permite decidir cuando necesitamos usar la herencia o “inheritance” para compartir el código entre varias clases.

De acuerdo a la sugerencia de Sandi para este tema, el utilizar la abstracción de la clase padre nos permite crear verdaderas especializaciones en las subclases como pueden observar aqui:

Un mecanismo o patrón que nos permite reducir en buena manera las dependencias entre la clase padre y las subclases es la utilización del patrón Template Method, o patrón de diseño de plantilla.

Finalmente para implementar una clase que hereda de otra utilizando el patrón de template, podemos observar que es necesario definir dos metodos en esta clase heredada pero no es necesario definir el initialize ni tampoco escribir super para delegar los parametros del mensaje.