Dispose pattern

“Не стоит следовать некоторой идиоме только потому, что так делают все или так где-то написано”
Мысли автора статьи во время чтения и рефакторинга чужого кода

Ни для кого не будет секретом, что платформа .NET поддерживает автоматическое управление памятью. Это значит, что если вы создадите объект с помощью ключевого слова new, то вам не нужно будет самостоятельно заботиться о его освобождении. Сборщик мусора определит «достижимость» объекта, и если на объект не осталось корневых ссылок, то он будет освобожден. Однако, как только речь заходит о ресурсах, таких как сокет, буфер неуправляемой памяти, дескриптор операционной системы и т.д., то сборщик мусора, по большому счету, умывает руки и весь головняк по работе с такими ресурсами ложится на плечи разработчика.

А как же финализаторы? – спросите вы. Ну, да, есть такое дело, финализаторы действительно предназначены для освобождения ресурсов, но проблема в том, что время их вызова не детерминировано, а это значит, что никто не знает, когда они будут вызваны и будут ли вызваны вообще. Да и порядок вызова финализаторов не определен, поэтому при вызове финализатора некоторые «части» вашего объекта уже могут быть «разрушены», поскольку их финализаторы уже были вызваны. В общем, финализаторы – они-то есть, но это скорее «страховочный трос», а не нормальное средство управления ресурсами.

Google+

Каждый блогописец или блоговод, не знаю, как назвать сее существо правильно, сталкивается со следующим вопросом: вот, дескать, появилась у него светлая мысль и хочется этой мыслью поделится с миром. При этом возникает дилемма: то ли сваять все побыстренькому, не заморачиваясь особенно с темой и ее раскрытием или же покумекать хорошенько и выдать контент более осмысленный.

Я всегда склонялся ко второму варианту и в большинстве случаев именно этому принципу и следовал при ведении этого блога. Это выливается в то, что посты в этом блоге более или менее походят на небольшие (а иногда и на вполне увесистые) статейки и практически никогда не умещаются на одной странице.

Такое отношение к блогописательству я считаю вполне разумным и продолжать хочу именно в том же духе. Но иногда, по мере брождения (или брожения, не знаю, как правильно) по просторам этих ваших интернетов, сталкиваешься с чем-то айтишно-интересным, или, читая какую-нибудь интересную книжонку, находишь некоторую мысль весьма интересной, что ею хочется поделиться. При этом оформлять это дело в статью обычно нет ни сил, ни желания. Постить же в этот блог неоформленные мысли и простые ссылки не хочется категорически.

Посему такую “нестатейную” нишу я заполняю с помощью гуглоплюса и живой ленты (твиттер как-то мне не удобен для этих целей, хотя им я тоже иногда пользуюсь). Посему, если ты, дорогой мой читатель, интересуешься не только моими статьями, но и не столь полноценно оформленными мыслями, то милости прошу в упомянутые выше гуглоплюс или живую ленту.

Сразу оговорюсь, что я совсем не фанат социальных сетей и не собираюсь постить всякую хрень, которой полным полно в интернете. В основном заметки в гуглоплюсе посвящены программированию и это всякие мысли, собственные наблюдения, размышления и т.п. Вот несколько последних постов для затравки:

• F#: непонятнки с литералами и паттерн-матчингом
• Profile Guided Optimization для С++ных проектов начиная с 2005-й студии
• О выступлении Гебра Саттера на BUILD конференции, посвященной современному С++
• Впечатления от проведения очередного семинара по асинхронному программированию
• О ковариантности спецификации исключений в языке С++

P.S. Ну, а кто на гуглоплюсе еще не зарегистрирован и нужен инвайт (там, кажется, он все еще нужен) – пишите, вышлю.

Принцип самурая

В мире разработки софта существует много идей и «метафор», позаимствованных из других, казалось бы, не сильно связанных с программированием областей. Можно вспомнить паттерны проектирования, позаимствованные у архитекторов, или понятие «технического долга», пришедшее из финансовой индустрии, да и «эффектом второй системы» страдают проектировщики любых систем, а не только программных (*). Все это упрощает коммуникацию между разработчиками или между разработчиками и заказчиками, а также упрощает понимание той или иной проблемы в разработке ПО.

Еще одной метафорой, или скорее принципом разработки, является «принцип самурая», призванный описать «контракт» между функцией и вызывающим ее кодом и заключается в следующем. Любая функция, реализующая некоторую единицу работы должна следовать тому же кодексу чести «бусидо», по которому живет любой самурай. Так, самурай не будет выполнять никаких заданий, противоречащих его «кодексу чести» и если к нему подойти с «непристойным» предложением, то он снесет вам башку раньше, чем вы успеете глазом моргнуть. Но если уж самурай возьмется за дело, то можно быть уверенным в том, что он доведет его до конца (**).

Вы, конечно, шутите, мистер Фейнман

Мое знакомство с мистером Фейнманом началось с перевода статьи Эрика Липперта «Что бы сделал мистер Фейнман». В этой замечательной заметке в виде шуточного рассказа приведены ответы на «нестандартные вопросы», так любимые некоторыми «мелкомягкими» компаниями при отборе кандидатов на работу. А поскольку мистер Фейнман всегда любил «нестандартные вопросы» и давал на них еще менее «стандартные ответы», то интервью получилось веселым и, как я узнал позднее, очень похожим на неопубликованную главу из книги «Вы, конечно, шутите, мистер Фейнман».

Сама же книга представляет собой сборник забавных и трогательных историй о жизни «простого» человека, по имени Ричард Филлипс Фейнман, самым незначительным достижением которого (по его собственному разумению) было получение Нобелевской премии по физике. Это книга о замечательном человеке, умном, талантливом, упрямом; человеке, у которого жажда познаний, экспериментов и решения разных головоломок была практически безграничной.