SOLID – Principio de Inversion de Dependencias
- No remitirse a clases concretas que cambien con facilidad: Nadie te niega que uses un String o una clase concreta nativa de Java, pero evita usar referencias a tus propias clases en desarrollo para evitar implantar cambios a cada minuto en las clases que la implementan.
- No realizar herencias desde clases concretas volátiles: Por el mismo motivo del caso anterior, es mejor no usar la herencia a no ser que estemos realmente necesitados de esta relación.
Las ventajas de usar este principio de diseño son varias y en distintas fases del desarrollo:
- Durante la fase de desarrollo de la aplicacion, no depender de concreciones nos facilitará el no reescribir varias veces código de módulos que dependan de ellos.
- Durante la fase de test, la interdependencia entre clases evita un buen desempeño a la hora de realizar pruebas unitarias.
- Durante la fase de mantenimiento, es mucho más sencillo realizar los cambios convenientes en los distintos módulos e incluso comprender sus dependencias.
Inyeccion de dependencias
Es posible que hayas escuchado alguna vez la expresion «inyección de dependencias» o «inversion de control». Si crees que tiene algo que ver con este principio, has acertado de pleno. La inyección de dependencias es un patrón de diseño central para algunos frameworks como Spring, que nos ayuda a desacoplar la creacion de los objetos de su utilizacion. Spring por ejemplo nos provee de un contenedor que se encarga de buscar y manejar el ciclo de vida de un determinado tipo de clases denominadas beans. Gracias a este contenedor podemos beneficiarnos de todo lo que supone seguir el DIP (Dependency Inversion Principle) que comentamos más arriba.
En este enlace puedes leer más sobre el Spring Container y la inyeccion de Dependencias.