Quiero refactorizar algunos códigos usando el framework Windsor IOC/DI, pero mi problema es que tengo algunas clases Singleton y clases de patrones de fábrica y no estoy seguro de que se pueda implementar Singleton o Fábrica usando DI.Patrones DI y Singleton en una implementación
¿Alguien tiene alguna idea si eso es posible y cómo?
El patrón de diseño Singleton está en desacuerdo con DI. Si bien es posible abrir un Singleton tanto que DI y el Open/Closed Principle comienzan a tener sentido, esto cambiará tanto el Singleton que casi deja de ser un Singleton.
La seguridad de subprocesos es un gran problema que se le viene a la mente cuando comienza a abrir un Singleton.
Es mucho mejor simplemente definir sus servicios y clases sin tener en cuenta su alcance demasiado. Si tiene un objeto que le gustaría compartir entre múltiples consumidores, la mayoría de los Contenedores DI tienen el concepto de vida útil de Singleton, que imita los beneficios del patrón de diseño Singleton sin sufrir ninguno de los inconvenientes.
En resumen: Singletons son malvados y deben evitarse.
Abstract Factory, por otro lado, es muy útil para fines DI.
No lo hagas, dejas que el contenedor IOC lo haga. Donde antes teníamos llamadas explícitas a una fábrica para obtener una instancia singleton de un objeto, ahora tiene el contenedor IOC para crear un gráfico de objetos para usted, y lo conecta todo donde corresponde. El contenedor se asegura de que sus singletons sean singletons, y actúa como la fábrica.
Si está hablando de tener una fábrica que decida en tiempo de ejecución qué tipo de objeto atender, DI no es aplicable allí, excepto que puede hacer que el contenedor DI inyecte la fábrica donde desee y administre su alcance para usted .
¿El marco de IOC tampoco tiene la capacidad de decidir qué objeto servir en tiempo de ejecución? Entonces, ¿por qué usar una fábrica de esa manera cuando se usa DI? Usaría una fábrica más para crear varias instancias de las mismas clases o similares ... –
Me refiero a cuando se utiliza IOC, no 'usando DI' –
Normalmente, los marcos IOC son bastante estáticos, crean objetos para usted en función de la configuración (xml, anotaciones, archivos de propiedades, lo que sea), así que no, no hay mucha capacidad para decidir qué crear sobre la marcha. –
La mayoría de los marcos modernos de inyección de dependencias le permiten especificar si deben servir una sola instancia de objeto durante la vida de la aplicación (o solicitud) o crear nuevas instancias cada vez que la solicite.
También puede usar un marco DI para resolver dependencias en fábricas cuando sea apropiado (si eso es lo que quiere decir). Puede hacer esto si la fábrica selecciona una subclase basada en datos de tiempo de ejecución, o si un objeto dependiente necesita crear muchas instancias IFoo, en cuyo caso puede inyectar un IFooFactory.
Me refiero a la última de crear muchas instancias de una determinada clase utilizando una fábrica, y luego tener que inyectar la fábrica en alguna clase. –
Singletons es algo que utilizo con bastante frecuencia, pero al leer esto, ¡parece que tendré que cambiar mi estrategia! Encontré que son bastante útiles en ciertas situaciones ... pero puedo ver de dónde vienes en la seguridad del subproceso. –
La seguridad del hilo es una cosa, pero el problema principal es la violación del principio abierto/cerrado. –
Si utilizo un contenedor DI para administrar el alcance de un singleton, ¿por qué es una violación de OCP? Debido a que no confío en los métodos estáticos para la implementación, aún puedo crear una subclase, creo que usar un contenedor DI para singletons me permite preservar el OCP. ? –