¿Cómo aplico la inyección de dependencia a una fábrica abstracta

Question

Acabo de terminar el libro inyección de dependencias de Mark Seemann en .NET y ahora estoy tratando de refactorizar algún código heredado. (En este momento, no estoy confiando en ningún contenedor DI particular, sino simplemente intentando mover todas las dependencias a un lugar).

estoy mirando a la siguiente clase de fábrica que determina la ArchiveType mediante la lectura de los primeros bytes del archivo con archiveReader.GetArchiveType() y luego devuelve una instancia de un ArchiveRestorer basado en la ArchiveType enumeración.

public class ArchiveRestorerFactory : IArchiveRestorerFactory 
{ 
    public ArchiveRestorer Create(ArchiveReader archiveReader) 
    { 
     ArchiveType type = archiveReader.GetArchiveType(); 
     switch (type) 
     { 
      case ArchiveType.CurrentData: 
       return new CurrentDataArchiveRestorer(archiveReader); 
       break; 
      case ArchiveType.HistoricalData: 
       return new HistoricalDataArchiveRestorer(archiveReader); 
       break; 
      case ArchiveType.AuditTrail: 
       return new AuditTrailArchiveRestorer(archiveReader); 
       break; 
      default: 
       throw new Exception("ArchiveRestorerFactory error: Unknown value for ArchiveType."); 
     } 
    } 
} 

¿Cómo refactorizar esto para que la clase no depende de los tipos de hormigón CurrentDataArchiveRestorer, HistoricalDataArchiveRestorer y AuditTrailArchiveRestorer?

¿Debo mover los tres restauradores de hormigón al constructor de la fábrica?

public ArchiveRestorer Create(ArchiveReader archiveReader, 
    ArchiveRestorer currentDataArchiveRestorer, 
    ArchiveRestorer historicalDataArchiveRestorer, 
    ArchiveRestorer auditTrailDataArchiveRestorer) 
{ 
    // guard clauses... 
    // assign to readonly fields 
} 

Ese parece ser el enfoque sugerido here, pero luego se va a crear una instancia de los tres restauradores cuando hace falta un único? ¿Qué pasaría si tuviera 20 implementaciones concretas posibles diferentes en su lugar?

Siento que debería implementar una fábrica de concreto para cada tipo de restaurador y devolverlo en su lugar, pero entonces simplemente reemplazaría uno new por otro.

¿Cuál es la mejor manera de refactorizar esto?

Answer 1

La forma en que lo haría, dado el código que ya tiene, sería crear una fábrica para cada uno de estos objetos que tiene un método Create().

Tendría también una interfaz para estas fábricas y las heredé de una interfaz general de fábrica.

Puede utilizar las interfaces como punto de inyección en su constructor.

Cuál sería llamado similar a esto:

case ArchiveType.CurrentData: 
       return _currentDateArchiveRestorerFactory.Create(archiveReader); 
       break; 

Alternativamente, podría ser mejor tener una sola fábrica que crea una instancia de un tipo dado. Como todos estos objetos son restauradores, puede crear la instancia basada en enum en lugar de switch.

_restorerFactory.Create(ArchiveType.CurrentData); 

Answer 2

Realice una interfaz con un método con retornos tipo de esa interfaz y dejó tres clases Archiver implementan esa interfaz y luego en el método de crear el tipo de parámetro sería sólo la interfaz y se devolverá el objeto requerido llamando el método de interfaz que acaba de crear. Entonces no necesita un tipo concreto en el método de creación.

Answer 3

interface ILogger 
{ 
    void Log(string data); 
} 

class Logger : ILogger 
{ 
    . 
    . 
    . 
} 

En este punto, se utiliza un objeto de fábrica intermedia para devolver el registrador para ser utilizado dentro del componente:

class MyComponent 
{ 
    void DoSomeWork() 
    { 
    // Get an instance of the logger 
    ILogger logger = Helpers.GetLogger(); 
    // Get data to log 
    string data = GetData(); 

    // Log 
    logger.Log(data); 
    } 
} 

class Helpers 
{ 
    public static ILogger GetLogger() 
    { 
    // Here, use any sophisticated logic you like 
    // to determine the right logger to instantiate. 

    ILogger logger = null; 
    if (UseDatabaseLogger) 
    { 
     logger = new DatabaseLogger(); 
    } 
    else 
    { 
     logger = new FileLogger(); 
    } 
    return logger; 
    } 
} 
class FileLogger : ILogger 
{ 
    . 
    . 
    . 
} 

class DatabaseLogger : ILogger 
{ 
    . 
    . 
    . 
} 

Answer 4

por qué no hacer el ArchiveReader responsable de crear el ArchiveRestorer apropiado?A continuación, la primera iteración del código se vería así:

public class ArchiveRestorerFactory : IArchiveRestorerFactory 
{ 
    public ArchiveRestorer Create(ArchiveReader archiveReader) 
    { 
     ArchiveRestorer restorer = archiveReader.GetArchiveRestorer(); 
     return restorer; 
    } 
} 

Para entonces, debería ser bastante obvio que la fábrica es redundante, por lo que en la segunda iteración del código se puede tirar a la basura dejó que los consumidores invocan el ArchiveReader directamente.

Answer 5

Resolvería este problema acordando una convención de nomenclatura y utilizando la capacidad de Unity para nombrar registros. Ejemplo de esto aquí: https://dannyvanderkraan.wordpress.com/2015/06/29/real-world-example-of-dependency-injection-based-on-run-time-values/