¿Pueden la inversión de control y RAII jugar juntos?

Question

Estaba leyendo sobre la inversión de control (IOC) y me molestaba que pareciera que hace que la gestión de la memoria sea un problema. Por supuesto, parece que ioc se usa principalmente en entornos recolectados de basura (Net, Java, Scripting), mientras que mi preocupación es en configuraciones que no sean gc.

Mi preocupación aquí es que el COI en cierto modo va en contra de RAII, ya que desacoplamos la vida útil del recurso de la duración del objeto. ¿Esta complejidad adicional no molesta a nadie más? Y la verdadera pregunta, ¿qué técnicas se pueden usar para que las cosas funcionen sin problemas?

Answer 1

Por esta misma razón he hecho mi propio contenedor de IoC que devuelve (en C# /. NET) envoltorios de servicio desechables, que cuando se desechan, "harán lo correcto" con respecto al servicio.

se trate de:

• No hacer nada, cuando:
  • El objeto no implementa IDisposable
  • No es contenedor de ámbito (en cuyo caso el contenedor se mantendrá un registro de la misma y de retorno el mismo objeto más de una vez, y cuando el contenedor se desecha, el objeto también lo estará)
  • No se ha agrupado
  • No es singleton -scoped (igual que el recipiente de ámbito, pero una jerarquía de contenedores almacenará el servicio singleton de ámbito en el recipiente superior)
• botar el servicio (tiene alcance de la fábrica, e implementa IDisposable)
• Return a la piscina

Esto significa que todo el código que utiliza mis servicios está dentro de un bloque usando, pero la intención es más claro, al menos para mí:

using (var service = container.Resolve<ISomeService>()) 
{ 
    service.Instance.SomeMethod(); 
} 

básicamente que sA ys: resuelva un servicio, llame a SomeMethod en la instancia del servicio y luego deséchelo.

Dado que el conocimiento de si disponer de la instancia de servicio o no no está disponible para el consumidor, se optó simplemente por ignorar las implementaciones IDisposable o deshacerse de todos los servicios que implementan IDisposable. Tampoco fue una buena solución para mí.La tercera opción fue envolver la instancia del servicio en un objeto que sabía qué hacer con el servicio una vez que se eliminó el envoltorio.

Answer 2

Lo primero que se me ocurrió fue SmartPointers. Y argumentos de plantilla. Pero no estoy seguro de si los argumentos de la plantilla cuentan como una técnica de IOC, aunque creo que deberían. Al menos estos pueden aliviar algunos problemas con el COI, pero no se venden por completo en la idea.

Answer 3

Sí y no. IoC no desacopla el tiempo de vida del recurso de la duración del objeto, desacopla el ámbito de invocación del método de la vida útil del objeto: muy a menudo quiere que exista objeto que se destruiría al final de un método hasta que se realice otra llamada IoC. Por lo tanto, debe mover los locals de un método al alcance de la clase y asegurarse de que ningún método sea reentrante, o adoptar otro enfoque, como tener un 'entorno' extra para permitir que los objetos sean de su propiedad, y destruido en posteriores llamadas al método IoC. Cualquiera de los dos enfoques se vuelve bastante complicado si quieres un sistema impulsado por eventos de propósito general: tus modelos terminan teniendo que implementar recurrencia e iteración explícita, o tu simple código RAII C++ se convierte rápidamente en un complejo nido de devoluciones de llamadas, lo suficientemente complejo que abandoné en C++ y RAII comenzó a trabajar en kin en su lugar.