Pull to refresh

Comments 13

А зачем тащить Fody в задачу, где достаточно базового класса? Не говоря уже о наличии таких готовых базовых классов в самом фреймворке.
Для меня проще использовать Fody, чем наследоваться от класса.
Плюс Janitor.Fody сам расставляет проверки с выбросами ObjectDisposedException, что универсальный базовый класс сделать не может в принципе.
А так на вкус и цвет все фломастеры разные.
Я просто посчитал правильным сначала рассмотреть те варианты, которые моя реализация не покрывает.

Я после того как начал использовать costura.fody тащу её теперь в каждый проект
Да, вы абсолютно правы.
Мне с неуправляемыми ресурсами приходилось сталкиваться крайне редко, и Janitor.Fody вполне хватало.
А если я не хочу Reactive Extensions тащить к себе в солюшен?
Напишите свои аналоги CompositeDisposable и Disposable.Create. Это несложно, благо Rx исходники никуда не прячет.
Сложность постобработки, в невозможности отладки такого кода, что часто критично.
На мой взгляд проще и вернее использовать каноническую реализацию из MSDN, а все остальное может породить сложно диагностируемые проблемы…
В данном конкретном случае критично совсем не это, а главное свойство CriticalFinalizerObject:
Гарантирует, что весь код завершения в производных классах помечен как критический

ну подход хорош тем, что вы вспомнили про SRP и выделили освобождение объекта в отдельную ответсвенность
На самом деле подход родился по ходу рефакторинга огромного количества легаси. Про SRP специально не думал, оно само получилось.

А что делать с исключением в конструкторе?

То же что и всегда. Только в коде аварийной очистки будет ровно одна строка.
Sign up to leave a comment.

Articles