Здравствуйте, _FRED_, Вы писали:
A>>Есть мнение, что нужно проектировать классы и методы таким образом, чтобы не было необходимости использовать using с полями класса или параметрами методов. :)
_FR>Ты же сам сообщением выше призывал всюду юзингом пользоваться!?
Где это я "призывал всюду юзингом пользоваться"? Просмотрел свои сообщения еще раз — не нашел никаких призывов.
Я писал, что конкретный приведенный выше код плохо выглядит, и после переделки смотрится куда лучше. Еще я писал, что считаю неправильным использовать переменную из юзинга вне этого юзинга. То есть это по определению получается локальная переменная, а не параметр метода или поле класса.
_FR>Я только заметил, что "везде" пользоваться юзингод нельзя.
Я там в предыдущем сообщении предлагал использовать Dispose руками. То есть, с данным утверждением я вполне согласен. Нельзя везде использовать юзинг. Юзинг надо использовать там, где объект должен быть гарантированно уничтожен после его использования. Исходя из этого, использовать объект за границами блока юзинг выглядит несколько странной идеей.
_FR>Если, как показано, использовать внутри using, то не получится вернуть из функции закрытый стрим.
Дык я и говорю — надо сделать так, чтобы не нужно было из метода возвращать стрим — то ли закрытый, то ли открытый, то ли вообще стрим.нулл. Передавать как параметр — бог навстречу, но возвращать... Старое доброе правило — кто (где) создал объект, тот (там) его и уничтожает — считаю очень даже правильным. Такое не всегда возможно, понятно. Но по-моему это должно быть исключением, а не правилом.
_FR>Широко известна рекомендация не возвращать "null" как результат типа string или IEnumerable (а использовать String.Empty и пустой енумератор). Для стримов полезно пользоваться тем же правилом. То есть, когда надо возвратить стрим и по каким-то причинам не удаётся, следует или бросить исключение или вернуть Stream.Null, но не "null".
Понял, спасибо. Правда, есть сомнения в целесообразности подобного (именно со стримом) — с точки зрения производительности. Думаю, ненужная работа со пустым стримом может в некоторых случаях занять ощутимое время. Или оптимизатор это все разруливает? Надо будет покопать по теме при случае, спасибо за наводку.