Multitudes construyendo una implementación. DI desesperada? ¿Usar el localizador de servicios?

Bueno, no estoy seguro de entender completamente los detalles técnicos y sus diferencias exactas de sus soluciones compatibles, pero en mi humilde opinión, primero debe averiguar qué tipo de flexibilidad realmente necesita.

Las preguntas que debes hacerte son:

• ¿realmente necesita una posibilidad de configuración entre diferentes implementaciones? ¿Con qué propósito?

• ¿necesita una mecánica de tiempo de ejecución, o simplemente una mecánica de tiempo de compilación para cambiar entre diferentes implementaciones? ¿Por qué?

• ¿Qué granularidad necesita para cambiar entre las implementaciones? ¿De repente? Por módulo (cada uno contiene un grupo de clases)? ¿Por clase?

• ¿Quién necesita controlar el interruptor? ¿Solo tu / tu equipo de desarrolladores? ¿Un administrador? ¿Cada cliente por su cuenta? ¿O los desarrolladores de mantenimiento para el código del cliente? Entonces, ¿qué tan fácil / robusto / infalible debe ser la mecánica?

Teniendo en mente las respuestas a estas preguntas, elija la solución más simple que se le ocurra y que le brinde la flexibilidad requerida. No implemente ninguna flexibilidad de la que no esté seguro "por si acaso" si eso significa un esfuerzo adicional.

Como respuesta a sus respuestas: si tiene al menos un caso de uso real , utilícelo para validar sus decisiones de diseño. Utilice ese caso de uso para averiguar qué tipo de solución funciona mejor para usted. Solo pruebe si una "fábrica" o un "localizador de servicios" le proporciona lo que necesita, o si necesita algo más. Si crees que ambas soluciones son igual de buenas para tu caso, lanza un dado.

Solo para asegurarme de que estoy haciendo esto bien. Tienes algún servicio hecho de algunas clases, por ejemplo, C1,...,Cn y un grupo de clientes que llaman directamente a new Ci(...) . Así que creo que estoy de acuerdo con la estructura general de su solución, que consiste en crear un nuevo servicio interno con algunas clases nuevas D1,...,Dn que sean agradables y modernas e inyectar sus dependencias (permitiendo esas dependencias a través de la pila) y luego reescribir Ci para no hacer nada más que crear una instancia y delgate a Di . La pregunta es cómo hacerlo y sugirió un par de maneras en 2 y 3 .

Para dar una sugerencia similar a 2 . Puede usar la inyección de dependencia en Di e internamente y luego crear una raíz de composición normal R (utilizando un marco si lo considera apropiado) que sea responsable de ensamblar el gráfico de objetos. Empuje R detrás de una fábrica estática y deje que cada Ci obtenga Di a través de eso. Así, por ejemplo, podría tener

public class OldClassI {
    private final NewClassI newImplementation;

    public OldClassI(Object parameter) {
        this.newImplementation = CompositionRoot.getInstance().getNewClassI(parameter);
    }
}

Esencialmente, esta es su solución 2, pero reúne todas sus fábricas en un solo lugar junto con el resto de la inyección de dependencia.

Comience con implementaciones sencillas, sencillas y sencillas.

Si más adelante necesita crear implementaciones adicionales, se trata de cuándo se produce la decisión de implementación.

Si necesita flexibilidad de "tiempo de instalación" (cada instalación de cliente utiliza una implementación única y estática), aún no necesita hacer nada sofisticado. Simplemente ofrece diferentes DLL o SO (o cualquiera que sea su formato de biblioteca). El cliente solo necesita colocar el correcto en la carpeta lib ...

Si necesita flexibilidad en tiempo de ejecución, solo necesitará un adaptador delgado y un mecanismo de selección de implementación. Si utiliza una fábrica, un localizador o un contenedor de IoC, en su mayoría es discutible. Las únicas diferencias significativas entre un adaptador y un localizador son A) Nombrar y B) Si el objeto devuelto es un singleton o una instancia dedicada. Y la gran diferencia entre un contenedor de IoC y una fábrica / localizador es quién llama a quién . (A menudo es una cuestión de preferencia personal.)