Problema con el COI: Demasiadas fábricas abstractas para las clases dependientes de los datos de tiempo de ejecución

Question

Recientemente comencé a usar DI en uno de mis proyectos. Para las clases dependientes del tiempo de ejecución, creé las fábricas abstractas correspondientes. Después de seguir este patrón, termino teniendo demasiadas fábricas abstractas, casi una para cada clase.

¿Es común terminar teniendo demasiadas fábricas abstractas cuando se usa IOC?

Escenario: Supongamos que obtengo un objeto "Entidad" de una base de datos. Hay 10 casos de uso diferentes que un usuario podría realizar en este objeto de entidad. Para cada uno de los casos de uso, tengo una clase diferente para manejarlo. En algunos casos, un caso de uso dado podría tener componentes de subusuario que también pueden necesitar el objeto de entidad. Como estas clases dependen del objeto de entidad en tiempo de ejecución, tuve que crear una fábrica abstracta para cada una de ellas. Finalmente conecto las instrucciones de construcción en el contenedor de IOC.

Hay una forma alternativa de hacerlo. Siento que crear todas estas fábricas es una pérdida de tiempo, ESPECIALMENTE cuando todas las subclases dependen del mismo objeto de entidad.

Me siento inclinado a tener una sola clase de fábrica/generador registrada para mi escenario con contenedor IOC. Esta fábrica crearía el gráfico de objetos requerido para mi escenario. Veo el COI como una herramienta para ayudar a implementar el concepto DI. No utilizar todo el paquete de IOC puede no ser malo siempre que observe DI a través de un generador/fábrica personalizado.

Quería saber qué piensan ustedes acerca de este enfoque?

Answer 1

Parece que padece una sobreabundancia de las interfaces 1: 1. Cuando eso sucede, a menudo es una señal de que uno debe detenerse y pensar en el Reused Abstractions Principle.

Quizás pueda rediseñar sus interfaces para que haya less factories and more commands.