C++ / El principio interface segregation

Bienvenidos sean a este post, hoy veremos uno de los principios de SOLID.

Este principio nos sugiere convertir interfaces complejas en interfaces mas simples. Esto permite que las clases eviten implementar una interface que no se usaran.

En nuestra aplicacion e-commerce deberiamos implementar el envio de los productos, reemplazo y funcionalidades de expiracion. El envio del producto no es otra que el movimiento del producto al comprador, y por el momento no nos centraremos en los detalles del envio. Reemplazo del producto consiste en el reemplazo del producto enviado ya sea por daño o perdida al momento del envio al comprador. Y por ultimo, expiracion es para deshacerse de productos que nos fueron vendidos antes de su fecha de expiracion. Y si bien somos libres de poder implementar todo tipo de funcionalidades en la clase Producto, no lo podremos para ciertos tipos de productos. Por ejemplo, el envio no sera para todos los productos, una casa no puede ser enviada al comprador, y despues tendremos productos que no pueden ser reemplazables. Tomemos como caso una pintura original, donde no puede ser reemplazada ante un daño o perdida, asi como los productos digitales no expiran, en la mayoria de los casos.

Por lo comentado anteriormente, no deberiamos forzar al codigo del cliente a implementar algo que no necesita usar. Cuando nos referimos al cliente, hablamos de la clase implementando las conductas. Veamos el siguiente codigo:

class IEnvioReemplazoExpira
{
public:
  virtual void envio() = 0;
  virtual void reemplazo() = 0;
  virtual void expira() = 0;
};

Este es un codigo de mala practica y que contradice completamente al principio. Si bien tendremos un metodo para cada conducta no es simple. Modifiquemoslo de la siguiente manera para que se ajuste al principio:

class IEnvio
{
public:
  virtual void envio() = 0;
};

class IReemplazo
{
public:
  virtual void reemplazo() = 0;
};

class IExpira
{
public:
  virtual void expira() = 0;
};

Esto si cumple con el principio porque cada conducta tendra su propia interfaz y nos permitiran implementar cada una de ellas en el producto que corresponda. Veamos el siguiente codigo de ejemplo:

class ProductoFisico : public Producto {};
class ProductoDigital : public Producto {};

class Libro : public ProductoFisico, public IEnvio, public IReemplazo {};
class Casa : public ProductoFisico, public IExpira {};
class AudioLibro : public ProductoDigital, public IReemplazo {};

Primero vamos a definir las dos clases de tipo de producto que podemos tener y ambas seran herederas de Producto, por un tema de simplicidad las dejaremos todas vacias. Con nuestros tipos de productos creados vamos a proceder a crear algunas clases de estas. La primera es para Libro, esta sera heredera del tipo fisico y tendra dos conductas. Estas seran para el envio y el reemplazo, la primera es porque es un producto fisico y la segunda es porque puede dañarse o perderse en el envio, eventos mencionados anteriormente. La siguiente clase es para una casa, tambien sera fisica pero solamente pasamos la conducta de expiracion. Porque eventualmente, la persona que lo vende puede establecer una fecha limite, puede arrepentirse, etc. Y esta no puede enviarse ni reemplazarse, por lo menos por ahora 😅. La ultima clase es para un Audiolibro y esta sera de tipo digitaal, como conducta pasaremos unicamente a reemplazo pero por el hecho de que le pasemos el archivo equivocado o una direccion equivocada. Aunque en el ultimo caso tambien podriamos implementar a envio, si queremos tomar la descarga o el path del archivo como un envio.

En resumen, hoy hemos visto al Principio de Segregacion de Interfaz, Segregation Interface Principle, que es, para que sirve, como se implementa, asi como un ejemplo simple de como se debe tratarlo. Espero les haya resultado de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.