13 - Dependencias entre clases

En el mundo del desarrollo de software, la relación entre clases es esencial para la construcción de sistemas robustos y mantenibles. La dependencia entre clases es una pieza fundamental en este entorno, donde una clase puede requerir los servicios o funcionalidades proporcionadas por otra para llevar a cabo su tarea.

Sin embargo, una dependencia fuerte entre clases puede llevar a un acoplamiento excesivo, lo que dificulta la flexibilidad y la reutilización del código. Es aquí donde entra en juego el concepto de desacoplamiento, que busca reducir la dependencia entre clases y promover la modularidad y la escalabilidad en el diseño de software.

En este contexto, es crucial entender los diferentes mecanismos que tenemos a nuestra disposición para lograr este desacoplamiento. Entre ellos, destacan la Inyección de Dependencias (DI) y el Inversión de control (IoC), que proporcionan técnicas efectivas para separar la configuración y la creación de objetos de su uso real, facilitando así la gestión de dependencias y la modularidad del código.

En este breve recorrido, exploraremos la importancia del desacoplamiento entre clases y cómo los mecanismos de DI y IoC nos ayudan a alcanzar este objetivo.

La Inyección de Dependencias (DI) es un principio fundamental en el diseño de software moderno que aborda la problemática del acoplamiento entre clases al permitir que las dependencias sean proporcionadas desde el exterior en lugar de ser creadas internamente. Este enfoque promueve la flexibilidad y la reutilización del código al separar la configuración y la creación de objetos de su uso real.

Para ilustrar la importancia de la DI, consideremos un ejemplo simple. Tenemos una interfaz InterfazX con dos implementaciones: ClaseC y ClaseD. Además, tenemos una clase ClaseB que depende de InterfazX para realizar sus operaciones. En la clase ClaseA, deseamos utilizar ClaseB, pero queremos poder elegir entre ClaseC y ClaseD como la implementación de InterfazX sin modificar directamente ClaseB. Usando DI podemos proporcionar flexibilidad al diseño del software al permitir la elección de implementaciones concretas de las dependencias en tiempo de ejecución, lo que facilita el mantenimiento y la evolución del código:

public interface InterfazX {
    void metodoX();
}

public class ClaseC implements InterfazX {
    public void metodoX() {
        System.out.println("Método X de ClaseC");
    }
}

public class ClaseD implements InterfazX {
    public void metodoX() {
        System.out.println("Método X de ClaseD");
    }
}

public class ClaseB {
    private InterfazX instanciaX;

    public ClaseB(InterfazX instanciaX) {
        this.instanciaX = instanciaX;
    }

    public void operar() {
        instanciaX.metodoX();
    }
}

public class ClaseA {
    public void metodoAConClaseC() {
        InterfazX instanciaClaseC = new ClaseC();
        ClaseB claseB = new ClaseB(instanciaClaseC);
        claseB.operar();
    }

    public void metodoAConClaseD() {
        InterfazX instanciaClaseD = new ClaseD();
        ClaseB claseB = new ClaseB(instanciaClaseD);
        claseB.operar();
    }
}

En este ejemplo, ClaseA tiene dos métodos, metodoAConClaseC() y metodoAConClaseD(), cada uno de los cuales crea una instancia de ClaseB utilizando una implementación diferente de InterfazX mediante la inyección de dependencias.

Además, la utilización de DI nos brinda la flexibilidad necesaria para substituir implementaciones con mocks durante las pruebas unitarias. Ésto nos permite simular diferentes escenarios y comportamientos de las dependencias, facilitando así la identificación y corrección de posibles fallos en el código. De esta manera, la DI no solo promueve la modularidad y la flexibilidad del código en nuestra arquitectura, sino que también mejora significativamente la calidad y la robustez de nuestras pruebas unitarias.

En una arquitectura por capas, la DI emerge como una herramienta fundamental para promover la modularidad y la flexibilidad del código. Con DI, podemos desacoplar las capas de nuestra aplicación al proporcionar las dependencias necesarias desde el exterior en lugar de crearlas internamente. Esto facilita la sustitución de implementaciones y la realización de pruebas unitarias, lo que contribuye a un diseño más mantenible y evolutivo:

@Controller
public class BookController {
    private BookService bookService;

    public BookController() {
        BookRepository bookRepository = new BookRepositoryImpl();
        this.bookService = new BookServiceImpl(bookRepository);
    }

public interface BookService {
}

public class BookServiceImpl implements BookService {

    private BookRepository bookRepository;

    public BookServiceImpl(BookRepository bookRepository) {
        this.bookRepository = bookRepository;
    }
}

public interface BookRepository {
...
}

public class BookRepositoryImpl implements BookRepository {
...
}

En nuestra arquitectura por capas, aprovechamos el poder de Spring para simplificar la gestión de controladores mediante la creación automática de Beans. Esto nos permite centralizar la lógica de enrutamiento y la gestión de solicitudes de manera eficiente.

Sin embargo, en esta etapa inicial, optamos por crear manualmente nuestros servicios en lugar de utilizar la inyección de dependencias automática que ofrece Spring (como por ejemplo, con la anotación @Autowired). Esta decisión nos brinda un mayor control sobre la configuración y la gestión de nuestras dependencias, permitiéndonos comprender mejor los fundamentos de la Inyección de Dependencias (DI).

En nuestro ejemplo, BookController crea una instancia de BookServiceImpl y BookRepositoryImpl manualmente en su constructor. Esta aproximación, aunque más rudimentaria, nos permite comprender cómo se gestionan las dependencias en una arquitectura por capas y nos prepara para explorar en futuras etapas el uso más avanzado de la inyección de dependencias automática en Spring.

El problema con el ejemplo anterior es que el controlador está creando objetos de tipo repositorio, con lo que la capa de presentación se está comunicando directamente con la de persistencia. Esto presenta un problema de acoplamiento indebido, ya que estamos mezclando la lógica de presentación con la lógica de acceso a datos.

Para resolver este problema, podemos usar el principio de Inversión de Control (IoC). IoC es un patrón de diseño que busca invertir el control de la creación y gestión de objetos. En lugar de que una clase controle la creación de sus propias dependencias, estas se inyectan desde el exterior.

Al aplicar IoC en nuestro sistema, podemos desacoplar el controlador de las implementaciones concretas de los repositorios. Esto promueve un diseño más modular y flexible, donde cada capa de la aplicación tiene una responsabilidad claramente definida.

La Inversión de Control (IoC) es un principio de diseño de software que busca invertir el control de la creación y gestión de objetos. Tradicionalmente, en la programación orientada a objetos, una clase es responsable de crear y gestionar sus propias dependencias. Sin embargo, con IoC, esta responsabilidad se traslada a un componente externo, el contenedor IoC.

El contenedor IoC es una infraestructura que se encarga de administrar la creación y gestión de objetos en una aplicación. Al delegar esta responsabilidad al contenedor IoC, las clases se vuelven más flexibles y desacopladas, lo que facilita la configuración, la extensión y el mantenimiento del sistema.

Existen varios mecanismos para implementar IoC, siendo la DI uno de los más utilizados. Con DI, las dependencias de una clase se pasan como parámetros en lugar de ser creadas internamente. Esto permite que las clases sean más flexibles y reutilizables, ya que pueden recibir diferentes implementaciones de sus dependencias sin modificar su código interno.

Por ejemplo, vamos a crear un contenedor de IoC para gestionar la creación de objetos de tipo servicio y repositorio:

public class BookIoCContainer {

    private static BookService bookService;

    private static BookRepository bookRepository;

    public static BookService getBookService() {
        if(bookService == null) {
            bookService = new BookServiceImpl(getBookRepository());
        }
        return bookService;
    }

    public static BookRepository getBookRepository() {
        if(bookRepository == null) {
            bookRepository = new BookRepositoryImpl();
        }
        return bookRepository;
    }

}

En este caso, hemos creado los métodos estáticos para simplificar el proceso. Al utilizar este contenedor, podemos obtener instancias de estas clases sin tener que crearlas directamente en nuestros componentes.

Fíjate que cuando creamos el servicio creamos la instancia de repositorio también, y, aprovechando la DI, se la pasamos al constructor del servicio.

Nuestro controlador quedaría:

public class BookController {

    private final BookService bookService;

    public BookController() {
        this.bookService = BookIoCContainer.getBookService();
    }

Es importante tener en cuenta que este contenedor de IoC es una implementación simplificada y manual. En aplicaciones más grandes y complejas, es común utilizar frameworks como Spring Framework, que proporcionan funcionalidades más avanzadas para la gestión de IoC, como la inyección de dependencias automática y la configuración basada en anotaciones. Estas herramientas simplifican aún más el desarrollo y la gestión de aplicaciones basadas en IoC.

Ejercicio 1

Modifica la práctica de la evaluación anterior para añadir DI y IoC.