Contêiner de DI / IoC x fábricas: onde eu configuro meu aplicativo e por quê?

Estou tentando descobrir quando usar o registro DIC / IoC para configurar meu software e quando usar fábricas, juntamente com o raciocínio por trás de qualquer uma dessas abordagens.

Estou usando o StructureMap como meu contêiner de DI (DIC), que é fácil de configurar usando registros. No DIC, praticamente todos os objetos registrados são estáticos no sentido de que eu não preciso alterar / trocar nenhuma implementação / instância no tempo de execução, uma vez que o DIC esteja configurado e configurado no DIC como singletons. No entanto, como meu software (SW) será executado em dispositivos diferentes, preciso selecionar um registro específico do dispositivo, dependendo do dispositivo em que o SW for executado, para configurar o hardware adequadamente.

Como a construção de alguns dos meus objetos requer leitura nos arquivos de configuração, estou usando fábricas para retornar essas instâncias ao DIC, a fim de separar a leitura da configuração da criação do objeto. Registrei os getters de fábrica no DIC para os tipos de plugins correspondentes.

Agora diga que eu tenho um tipo de plug-in IMotorcom tipos concretos Motor1e Motor2, que deve ser tratado por uma fábrica. Agora, existem duas maneiras de decidir como configurar meu dispositivo:

1. Eu passo informações sobre o dispositivo em que o SW está executando MotorFactorye retorna o motor correto, Motor1ou Motor2. Nesse caso, a lógica para decidir está dentro da fábrica.
2. Eu configuro o DIC de acordo com o dispositivo em que ele está sendo executado e crio duas fábricas Motor1Factorye Motor2Factory, onde uma cria Motor1e a outra Motor2. Nesse caso, eu teria entradas de registro diferentes para IMotoros registros específicos do dispositivo que usam Motor1Factoryou Motor2Factory.

Agora, minha pergunta é: Qual desses dois métodos é preferível e por quê? Para mim, parece que o primeiro caso não é direto e complicado, pois estou espalhando a lógica que decide que tipo instanciar a base de código. Enquanto no segundo caso estou multiplicando efetivamente o número de fábricas no meu código, pois precisarei de uma fábrica para (quase) cada tipo de concreto. Torna-se ainda mais confuso para mim, quando fábricas abstratas são adicionadas à mistura.

Novamente: quando devo usar um método ou outro? E mais importante: quais são os bons indicadores para decidir qual caminho seguir?

Se você usar os dois, tentarei algo simples:

• DI / IoC: para todas as configurações que não são alteradas no tempo de execução.
• Factory: para criar instância de objetos em tempo de execução, que depende dos parâmetros de entrada em tempo de execução. As instâncias da fábrica são injetadas pelo recipiente DI.

Fábricas abstratas são usadas quando você tem objetos relacionados por meio de uma hierarquia que precisa variar juntos. Eu não vejo isso aqui.

O que vejo é que você está se perguntando se uma fábrica deve escolher o motor ou se o DIC deve escolher uma fábrica que produz um motor específico.

É difícil escolher exatamente porque uma fábrica e uma DIC fazem coisas muito semelhantes. A diferença é que a fábrica está focada em uma questão específica e o DIC é mais geral.

Tudo se resume a essa pergunta: você precisa de um código específico para esse problema que ficará na fábrica? Ou é mais geral como ler detalhes de configuração de um arquivo?

Lembre-se de que, embora você possa escolher apenas entre Motor1e Motor2hoje, amanhã poderá haver um Motor3. Favorecer o design que Motor3facilitaria a adição.

Eu separaria a lógica "qual motor usar" em uma fábrica especial chamada Builder (padrão) e usaria o IOC-Container para ambos os motores como detalhes de implementação do construtor.

Como uma regra geral:

• você precisa de uma fábrica (ou de um construtor) se precisar criar muitos objetos dinâmicos da classe / interface. (ou seja, para cada carro que você produz, você precisa criar um novo motor)
• se você precisar de apenas uma instância estática de uma classe, o ioc / di poderá fazer o trabalho por você (ou seja, você precisará apenas de uma instância estática do serviço de pagamentos e uma instância estática do MotorBuilderService)