Может инверсия управления и игры RAII вместе?
Те 100 строк кода Python, которые составляли 80% Вашего времени выполнения.
3 ответа
Именно по этой причине я создал свой собственный контейнер IoC, который возвращает (в C # /. NET) одноразовые служебные оболочки, которые при удалении будут «делать правильные вещи» в отношении служба.
Будь то:
- Ничего не делать, когда: Поскольку для потребителя было доступно либо полное игнорирование реализаций IDisposable, либо удаление всех служб, реализующих IDisposable. Для меня это тоже не было хорошим решением. Третий вариант заключался в том, чтобы обернуть экземпляр службы в объект, который знал, что делать со службой после удаления оболочки.
Да и нет. IoC не отделяет время жизни ресурса от времени жизни объекта, он отделяет область вызова метода от времени жизни объекта - очень часто требуется, чтобы объект, который был бы уничтожен в конце метода, существовал до тех пор, пока не будет сделан другой вызов IoC. Таким образом, вам нужно либо переместить локальные переменные метода в область класса и убедиться, что метод не повторяется, либо принять другой подход, например, передать дополнительную `` среду '', чтобы объекты могли принадлежать этому, и уничтожить в последующих вызовах методов IoC. Любой подход становится довольно сложным, если вам нужна система общего назначения, управляемая событиями - либо ваши модели в конечном итоге должны реализовать явную рекурсию и итерацию сами, либо ваш простой код RAII C ++ быстро превращается в очень сложное множество обратных вызовов - достаточно сложное, что я отказался на C ++ и RAII вместо этого начал работать над kin .
Первое, о чем я подумал, - это SmartPointers. И аргументы шаблона. Но я не уверен, что аргументы шаблона считаются приемом IOC, хотя я думаю, что должны. По крайней мере, это может решить некоторые проблемы с IOC, но не полностью соответствует идее.