Фриман и Фриман. Паттерны проектирования

DISCLAIMER: не проматывайте этот пост только из-за того, что обзор книг – это неинтересно. Здесь будет пяток интересных цитат и ряд других полезных мыслей!

Если спросить у десяти разработчиков о паттернах проектирования и о том, какая книга является лучшим источником информации по этой теме, то 9 из 10 назовут знаменитую книгу банды четырех и будут правы. GoF – является классическим каталогом паттернов в том виде, в котором он был описан Кристофером Александером 35 лет назад и все еще остается бесценным справочником для любого программиста.

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

C++ 11 FAQ от Бьярна Страуструпа

Примечание переводчика

Данный FAQ переводится на русский язык с любезного разрешения его автора - Бьярне Страуструпа. На данный момент работа над оригиналом этого документа еще не закончена, поэтому по мере изменения или дополнения оригинала, будет изменяться и перевод. Все пожелания/замечания по качеству перевода присылайте по почте, либо через профиль Google.

По просьбам читателей, я выложил сверстанную в pdf версию перевода, а также оригинал перевода в docx формате.

В формате pdf: http://bit.ly/StroustrupFAQRus_pdf
В формате docx: http://bit.ly/StroustrupFAQRus_docx

Благодарности: огромное спасибо Володе Тихонюку за вычитку материала и ценные советы!

Последние изменения в оригинале: 23.02.2012

С++11 – принятый недавно новый ISO стандарт языка С++

Этот документ написан и поддерживается Бьярне Страуструпом (Bjarne Stroustrup). Конструктивные комментарии, поправки, ссылки и предложения всецело поддерживаются. Сейчас я работаю над полнотой материала и приведением в порядок ссылок.

C++11 – это стандарт языка С++ утвержденный Международной организацией по стандартизации (ISO) в 2011-м году. Предыдущие версии стандарта обычно называют C++98 или C++03. Различия между С++98 и С++03 настолько специфические и их настолько мало, что на них можно не обращать внимания.

Доступна последняя версия рабочего документа, и она близка к окончательной версии черновика стандарта, формально принятого единогласным решением (21-0) в августе 2011 года.

До официального утверждения, будущий стандарт называли C++0x. К сожалению, у меня пока что не было времени везде обновить имя стандарта, вы уж простите, и вообще, мне очень нравится название C++ 0x :-). Название “C++ 0x” осталось с тех давних пор, когда мы надеялись, что новый стандарт будет называться C++08 или C++09. Сейчас можно рассматривать “x” в имени, как признак шестнадцатеричного формата (т.е. C++0B == C++11).

Все официальные документы, связанные со стандартом C++11/C++0x можно найти на официальном веб-сайте комитета по стандартизации. Официальное имя комитета SC22 WG21.

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

Инициализаторы объектов в блоке using

UPDATE: наткнулся на объяснение данного поведения Эриком Липпертом (подробности здесь).

Инициализаторы объектов (Object Initializers) – это полезная возможность языка C#, которая позволяет инициализировать необходимые свойства объекта прямо во время его создания. Поскольку синтаксически эта «фича» очень близка к инициализации объекта с передачей параметров через конструктор, многие разработчики начинают забивать на принципы ООП (в частности на понятие инварианта) и использовать ее, где только можно.

Но даже если не переходить к холиварам и малопонятным терминам, давайте рассмотрим небольшой пример, и подумаем над тем, может ли он привести к проблемам или нет:

// position передается извне или настраиватся каким-то образом
long position = -1;
using (var file = new FileStream("d:\\1.txt", FileMode.Append)
                        {
                            // Мы точно знаем, что нужные данные расположены
                            // с некоторым сдвигом!
                            Position = position
                        })
{
    // Делаем чего-то с файлом
}

В данном фрагменте внутри директивы using создается ресурс (файл) и устанавливается одно из его свойств (Position) с помощью инициализатора объекта. При этом самое главное в этом коде то, что setter этого свойства может генерировать исключение.

О повторном использовании кода

Сегодня существуют разные мнения по поводу успешности объектной технологии. С одной стороны, большинство современных mainstream языков программирования являются объектно-ориентированными, с другой стороны, нередко можно услышать критику ООП, дескать, объектно-ориентированное программирование «провалилось» и не оправдало тех надежд, которые были возложены на нее индустрией разработки ПО. Все, мол, ожидали наступления вселенского счастья в виде увеличения повторного использования, упрощения сопровождения, да и вообще, обещали, что думать придется кому-то другому, а я за это буду деньги получать.

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

Так вот вопрос: как же можно достичь той заветной мечты, когда системы можно будет строить из готовых компонентов, не написав при этом ни строчки кода? Я не уверен, что в таком виде эта мечта вообще осуществима из-за неотъемлемой сложности ПО, а также потому, что часто само решение влияет на решаемую задачу. Тем не менее, если направить энергию, затрачиваемую на повторное использование в правильное русло, то с разумным количеством трудозатрат можно поднять «реюз» кода на достойный уровень.

Видеоматериалы, блоги и подкасты для .NET разработчика

Видеоматериалы

В одной из своих статей Бьёрн Страуструп (папа С++) признался, что он не признает видео материалы в качестве источника для самообразования. И с ним сложно не согласиться, когда речь касается изучения с нуля языка программирования или технологии. Я правда сомневаюсь, что можно одолеть такого монстра, как С++ или стать гуру WPF лежа на диване и просматривая обучающее видео типа «Узнай все за 24 часа». Но если вы ставите себе цель познакомиться с некоторой технологией или новой возможностью языка программирования, или просто послушать философско-компьютерные размышления умного товарища, то в этом случае веб-касты, записи конференций или другой вид видеоматериалов может быть очень кстати.

Если постараться найти обучающее видео (а не просто интервью или выступления с конференций) для .NET разработчика, то первым и, пожалуй, единственным источником будет Pluralsight.

Pluralsight

Большая часть курсов Pluralsight посвящены технологиям компании Майкрософт: .NET, C#, F#, WCF, SQL Server, Windows Azure, Windows 8 и т.д. Другие же курсы посвящены фундаментальным знаниям и не привязаны к конкретным технологиям: HTTP Fundamentals, NoSQL, Source Control, практики разработки ПО и т.п.; есть даже курсы, посвященные Java, Ruby, разработке под iOS и Android (одним словом, в каталоге можно найти курс практически по всем популярным нынче баззвордам).

Что значат для вас юнит-тесты?

С технической точки зрения юнит-тесты – это очень простой инструмент, основанный на паре несложных концепций: (1) тестируемый класс, (2) набор тестовых методов, завернутых в некоторый класс и (3) набор методов, с помощью которых можно удостовериться в том, что состояние тестового класса соответствует (или не соответствует) некоторому значению.

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.

Замыкание на переменных цикла в C# 5.0

Многие разработчики языков программирования, библиотек, да и классов простых приложений стремятся к интуитивно понятному интерфейсу создаваемых классов. Скотт Мейерс еще полтора десятка лет назад сказал о том, чтобы мы стремились разрабатывать классы (библиотеки, языки), которые легко использовать правильно, и сложно использовать неправильно.

Если говорить о языке C#, то его разработчики подходят к вопросам «юзабилити» весьма основательно; они спокойно могут пожертвовать «объектной чистотой» в угоду здравому смыслу и удобству использования. Одним из немногих исключений из этого правила является замыкание на переменной цикла, той самой фичи, которая ведет себя не так, как считают многие разработчики. При этом количество недовольства и недопонимания настолько много, что в 5-й версии языка C# это поведение решили изменить.