Bienvenidos sean a este post, hoy veremos uno de los principios de SOLID.
Este principio enuncia que los objetos no deben estar fuertemente acoplados, y permitir que se cambie a una dependencia alternativa facilmente. Pensemos en el caso de cuando un usuario compra un producto, por esta accion debemos enviarle un recibo de esta compra. Para realizar esto tenemos varias maneras:
- Imprimir el recibo y enviarlo por correo
- Enviarlo directamente por email
- Mostrarlo en la pagina de la cuenta del usuario en la plataforma
Para el ultimo caso, debemos enviar una notificacion via email o mediante la app para indicar al usuario que ya puede visualizarla. Veamos el siguiente codigo:
class IEnvioRecibo
{
public:
virtual void enviar_recibo() = 0;
};
Una interfaz simple para implementar un metodo para el envio del recibo, este es una virtual pura. Supongamos que ya tenemos un metodo para realizar las compras, y cuando este finaliza envia el recibo. Veamos un ejemplo de como seria:
class Producto
{
public:
// codigo omitido por brevedad
void compra(IEnvioRecibo* recibo) {
// omitimos el codigo del metodo
recibo->enviar(/* informacion de la compra */);
}
};
En el metodo pasamos un objeto del tipo de la interfaz, luego procesamos la compra con todo el codigo correspondiente y una vez finalizado procedemos a enviar la informacion para generar el envio del recibo. Pero como mencionamos anteriormente no tenemos una sola forma de enviar el recibo, vamos a ver el siguiente codigo para implementar el primer envio:
class ReciboCorreo : public IEnvioRecibo
{
public:
// codigo omitido por brevedad
void enviar_recibo() override { /* ... */ }
};
Aqui implementamos una clase para el envio del recibo por correo normal, observen como usamos a la interfaz para ello y definimos al metodo encagado de eso con su correspondiente codigo. Esto debemos hacer para las otras maneras de envio de recibo, supongamos que tenemos las dos maneras antes comentadas. Con esto podemos definir dos clases similares a la anterior con los nombres ReciboEmail y ReciboEnApp que seran para enviar el recibo via email y notificacion de la aplicacion respectivamente. En estos dos casos tambien deben implementar a la interfaz y definir al metodo de este. Veamos un ejemplo de como puede ser usado:
IEnvioRecibo* rec = new ReciboEmail();
auto producto = get_producto_comprable();
producto.compra(rec);
Generamos el objeto de una de las clases que manejan el envio de recibos, para este caso usamos la encargada de enviar el recibo por email, y luego definimos un objeto que almacenara al producto que puede ser comprado, suponiendo que este metodo esta definido, y por ultimo en este objeto usaremos al metodo compra que comentamos anteriormente y le pasamos el objeto de como enviaremos el recibo. Inclusive esto se puede mejorar mas, simplemente implementandolo en la clase Usuario para que realice el envio del recibo al usuario concreto. Esto hara que las clases esten mas desacopladas.
Este es el ultimo principio de SOLID, si pasaron por los posts anteriores notaran que esto es forma natural de componer a las clases. Si bien estos principios no son obligatorios, el uso de ellos puede ayudarnos de gran manera en nuestro diseño.
En resumen, hoy hemos visto el Principio de Inversion de Dependencia, Dependency Inversion Principle, que es, para que sirve, como se aplica, y como podemos usarlo para nuestro proyecto. 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.


Donación
Es para mantenimento del sitio, gracias!
$1.50
