Поскольку камрады выразили желание увидеть в одном месте все комментарии к столь известной и уважаемой книге, как "Принципы, паттерны и методики гибкой разработки" Боба Мартина, то я решил таки собрать все замечания в одном месте.
На самом деле, это не первая такая заметка и есть как минимум три статьи с критикой вещей, описанных в этой книге. Вот краткое содержание предыдущих серий:
Вы когда-нибудь бросали чтение классической книги после прочтения двух десятков страниц, толком не понимая, почему же ее так хвалят и что же со мной не так? При этом я не говорю за книги, типа банды четырех, о которой говорят на каждом шагу, но при этом есть лишь четыре человека в мире, которые прочитали ее от начала до конца. И я тем более не говорю за книги Дональда Кнута на прочтение которых нужно потратить минимум 3 жизни. Я говорю о чем-то попроще, типа DDD Эванса или Корпоративных Шаблонов Фаулера.
Вы начинаете читать книгу, читаете несколько страниц и ловите себя на мысли, что думаете о чем-то совершенно левом. Вроде бы и тема интересная и слова важные, всякие там «стратегии архитектурного проектирования» и «принципы борьбы со сложностью», но понимаете, что эти слова как-то мало для вас значат и в голове не возникает никаких образов и мыслей о том, что же хочет сказать автор.
Именно такая ситуация у меня была с книгами Эванса «Предметно-ориентированное проектирование» и «Проектирование процесса проектирования» Брукса. Я начинал читать классику о DDD дважды, но каждый раз бросал через 20 страниц; тогда я думал, что у меня не было нужного настроя, но в этот раз я, кажется, понял, в чем была причина.
Да, все верно, первый пост был опубликован ровно 5 лет назад, 2 декабря 2008 года и назывался “LINQ to Objects. VS2008 SP1 Bug” и был посвящен тому, что в VS2008 следующий код:
UPDATE (заменил Select на Cast), спасибо Eugene Ivanchenko:
var bytes = Enumerable.Range(1, 5).Cast<byte>().ToList();
работал нормально, а в VS2008 SP1 падал с ошибкой. Это теперь мы знаем, что так и должно быть и распаковка типа с конвертацией всегда завершается с ошибкой, но тогда это поведение казалось ошибкой.
С тех пор опубликовано две сотни постов и, что самое главное, мне это продолжает нравитьсяJ
“NoSQL Distilled” – это последняя книга Мартина Фаулера, посвященная модной ныне технологии NoSQL. Эта книга является финалистом престижной премии Jolt Award этого года и написана в стиле, аналогичном другой книге Фаулера – UML Distilled. Соавтором Мартина является Pramodkumar Sadalage, автор очень толковой книги “Refactoring Databases: Evolutionary Database Design”.
В этой заметке я отталкиваюсь от определения архитектуры, которое предложил Мартин Фаулер в своей статье “Who Needs an Architect?”, перевод которой я публиковал в прошлый раз.
В чем главное отличие WCF от своих предшественников, таких как .NET Remoting, веб-сервисы, MSMQ или более старых технологий, таких как DCOM?
Расширяемость? Так .NET Remoting тоже содержит 100 500 слоев и расширяем донельзя. Возможность взаимодействия с приложениями на других платформах? Так это же умели делать и веб-сервисы. Ориентированность на обмен сообщений? Так именно эта идея заложена в основе MSMQ.
Кто такой архитектор и что такое архитектура? На самом деле, на эти вопросы нет простого и понятного ответа. Есть стандарты, в которых даются определения этим терминам, но они как всегда унылы чуть более, чем полностью.
Недавно я наткнулся на статью Мартина Фаулера “Who Needs an Architect?” и просто не смог пройти мимо, поскольку в ней даются очень интересные определения архитектора и архитектуры. Ниже представлен перевод этой статьи с моими аннотациями по ходу дела.
(Каждый из вас может получить самостоятельное представление о содержимом этой книги по адресу – programmer.97things.oreilly.com)
Представьте, что вы просыпаетесь среди ночи с озарением: я хочу написать книгу! Вы при этом понимаете, что писать книгу с нуля муторно, наработок толком нет, да и с темой еще не определился. Но поскольку уснуть не получается, то вы бродите по дому всю ночь в поисках решения. И вот, когда за окном уже начинает светать к вам приходит озарение: миру не хватает книги с общими советами, бесполезными любому программисту! Менеджерам повезло, для них уже вышла книга "97 Things Every Project Manager Should Know", так почему бы не сделать аналогичное доброе дело для программистов?!
Сказано – сделано! Все, что нам нужно, это найти 5 десятков авторов разной степени известности и попросить их поделиться своими сакральными знаниями! От каждого из них нам потребуется всего ничего: вумных мыслей в размере не более одной страницы! А что если у автора уже есть свои известные статьи? Тем лучше, тогда мы попросим выкинуть из нее весь код и "скукожить" в размерах, чтобы даже самому автору она перестала быть понятной! После этого, мы возьмем сотню заметок на самую разную тематику, выкинем 3 лишних, чтобы получить волшебное число 97, тщательно их перемешаем, чтобы от последовательного чтения книги вообще не осталось никакого смысла, напишем введение и ... вуаля, книга готова!
Когда речь заходит об абстракциях и инкапсуляциях, то обычно у нас в голове появляется образ класса, с разделением его интерфейса и реализации. Однако мы значительно реже используем тот же самый подход для более крупных строительных блоков, таких как модули (пакеты в Java или сборки в .NET). У сборки, также как и у класса, есть открытый интерфейс (абстракция) состоящий из набора открытых типов и закрытая часть (реализация), представленная в виде внутренних (internal) типов.
Все мы знаем, что нам следует значительно больше внимания уделять открытой части сущностей (интерфейсам в ОО понимании), поскольку изменения в этой части влияют на существенно большее количество других сущностей. Однако когда речь заходит о модулях (пакетах или сборках), то помимо разделения на открытую/закрытую части очень важно понимать, как и где эти модули используются.
DISCLAIMER: В некотором роде, это рецензия на книгу Чада Фаулера “Passionate Programmer”, но, как обычно, здесь будет много мыслей, основанных не только на этой книге.
В отличие от многих современных гиков, я не программирую с 13 лет, я не участвовал в областных школьных олимпиадах по математике или информатике, мой путь получился несколько иным. В универе я изучал системы управления и автоматики, а computer science закончилась на втором курсе курсовой работой на С++. Моя карьера программиста началась на пятом курсе, когда мой хороший знакомый позвал "попробовать себя" в качестве разработчика охранных систем. Я попробовал и понял, что я нашел себя, и что именно в этом направлении я хочу прикладывать усилия для развития себя, как специалиста.
Любопытный момент произошел где-то через полгода после начала моей работы. Как-то при встрече с друзьями-одногруппниками я стал увлеченно рассказывать о чем-то новом, что недавно открыл для себя в новом мире разработки ПО. Возможно делился впечатлениями от прочтения книги Гради Буча, а может речь шла о чем-то другом, уже не помню точно. Тогда один из моих друзей, который пошел работать на год или полтора раньше меня, сказал: "Серега, ничего, через годик тебя попустит, и ты станешь относиться к своей работе попроще". С того момента прошло уже около десяти лет, а меня так и не попустило:)
После наведения порядка с книгами пришло время выделить все статьи в отдельную заметку и сделать такую себе карту блога.
Ниже приведены наиболее значимые и интересные статьи, разбитые по разным тематикам, типа “Проектирования по контракту” или “C# Tips and Tricks”. При этом статьи представлены в порядке, наиболее удобном для изучения соответствующей темы, а не в хронологическом порядке. Наиболее значимые статьи, с моей точки зрения, выделены жирным.
Многие, наверное, слышали о такой книжно номинации, как Jolt Award. Многие известные книги являются лауреатами этой премии, что дает +100 500 к ЧСВ автора и примерно столько же к количеству скачанных экземпляров в торрентах.
Но сегодня речь пойдет не о том, кто, где и как достает книги, а о том, что стоит почитать, если на досуге вдруг появится пара десятков часов свободного времени, а люимая книга Мейера уже прочитана до дыр.
Тем более, буквально вчера Dr.Dobbs Journal, который выдает эти призы, опубликовали лучшие книги прошлого (2012-го) года. Я прошелся по списку номинантов и победителей этой премии за всю ее историю (полтора десятка лет) и получил вот такой список.
Замечали ли вы за собой, своими коллегами или друзьями одну интересную особенность: когда у кого-то начинает что-либо хорошо получаться, то почти всегда найдутся «подражатели», которые попытаются повторить тот же самый успех, путем копирования видимых действий оригинала? При этом обычно, это подражание ни к чему не приводит, поскольку «подражатель» начинает копировать лишь несколько видимых аспектов, без понимания всех внутренних причин успеха.
Первые примеры такого подражания легко увидеть у детей или подростков. Вспомните, как мы встречались мальчишками осенью и кто-то начинал хвастаться своими бицепсами. Сразу же вокруг него соберется группа однокашников, страстно желающих узнать рецепт успеха. При этом самое смешное, наблюдать, как избирательно работает наш мозг, который воспринимает лишь то, что мы хотим услышать. Так во фразе: "я тренировался на турнике каждый день по 40 минут в течении трех месяцев", мы услышим лишь «тренировался на турнике» и будем озадачены отсутствием результата через неделю, подтянувшись за все это время 4 раза. "А, турник – это не для меня! У меня мышцы спины слабые" ("руки слишком длинные", "турник во дворе кривой", "нет подходящих перчаток" и т.п.), услышим мы через неделю, когда энтузиазм ребят начнет спадать.
Есть множество исследований по поводу того, как происходит распространение инноваций в мире. Согласно большинству из них, большинству отраслей требуется 10-15 лет для принятия инноваций, но проблема в том, что в области разработки ПО этот срок существенно выше.
На самом деле, в нашей области нового существенно меньше, чем может показаться, и если посмотреть на «современные» методики разработки или технологии, то окажется, что исследования в этой области появились 10, 20, 30, а то и более назад.
Исследователи выделяют 5 категорий людей, в зависимости от их отношения к инновациям [Макконнелл2003]:
Ни у кого не возникало мыслей, что System.IO в наших с вами дот нетах проектировали специально, чтобы максимально запутать бедных программистов? Вот я, например, постоянно путаюсь между этими TextReader-ами, StreamReader-ами, StringReader-ами, классами FileStream и System.IO.File и т.п.. Поэтому я решил сделать небольшую шпаргалку для себя, но она может быть полезна и кому-то еще.
DISCLAIMER: это относительно продвинутая статья о сборке мусора, поэтому автор предполагает минимальное знакомство читателя с принципом работы сборщика мусора CLR.
Вопрос: может ли объект стать достижимым для сборки мусора до окончания вызова конструктора?
Поскольку объект не может контролировать процесс своего уничтожения, то этот вопрос можно перефразировать так: может ли финализатор вызваться до окончания вызова конструктора?
Но вместо того, чтобы сразу отвечать на эти вопросы, давайте рассмотрим основные особенности сборки мусора и ответим на более простые вопросы.
Никогда не задумывались о том, что значит булевый флаг trackResuraction в конструкторе WeakReference и что же такое short weak reference и long weak reference? Есть шансы, что вы не задумывались об этом просто потому, что никогда этих зверей не использовали в своем коде. Я тоже не особо задумывался об этой разнице, но вот, давеча, решил разобраться с этими вещами более подробно.
ПРИМЕЧАНИЕ
Разница между short и long weak references существует лишь при работе с финализируемыми объектами. Выходит, что это весьма специфическая тема, но ее рассмотрение позволит чуть глубже разобраться с внутренним устройством и поведением сборщика мусора.
Итак, давайте вспомним, что происходит при создании объекта А, содержащего финализатор:
Совершенно оправданно книга камрада Рихтера “CLR via C#” считается лучшей в своей роде. Более детального описания платформы .NET сложно найти, да и его книги по внутреннему устройству Windows тоже совершенно уникальны.
Но в его книгах (в особенности CLR via C#) есть ряд не вполне адекватных советов по дизайну наших с вами приложений. Так, Рихтер весьма категоричен при описании паттерна Dispose, который вполне валиден для разработчика библиотек, но сомнителен для разработчиков приложений.
И вот еще один весьма сомнительный совет по поводу необходимости явного вызова метода Dispose:
“Важно. В общем случае, я очень не рекомендую явно вызывать метод Dispose в вашем коде. Дело в том, что сборщик мусора CLR хорошо написан, и вы позволить ему делать свою работу. Сборщик мусора знает, когда объект становится недостижимым из кода приложения, и только тогда уничтожит его. Когда явно вызывается метод Dispose, то, по сути, это говорит, что приложению объект больше не нужен. Но во многих приложениях невозможно знать точно, что объект больше не используется.
Все-таки решил выделить все свои рецензии, обзоры и анонсы книг в отдельную статью, которая будет доступна с главной страницы и будет пополняться по мере поступления чего-то нового.
Интересно, как я читаю книги?
Интересно, что я еще читаю?
И хотя эти книги являются раем для читателя, их невероятно сложно писать. Чтобы понять это, достаточно попробовать написать статейку из серии "Используйте/не используйте эту возможность языка C#" или просто вспомните какой-нибудь холи-ворчик у себя в коллективе, который начался невинной фразой, "а давайте везде будем использовать as вместо оператора приведения типов" или другой подобной фразы.
Проблема любых советов из серии используй/не используй/избегай в том обилии исключений, которые следуют за любым подобным правилом. Вот, например, стоит ли использовать изменяемые значимые типы (mutable value types)? Любой программист, пришедший в .NET из С++ ответит положительно (ведь так быстрее!), потом он прочитает о проблемах и его мнение наверняка изменится на противоположное. После чего, в его голове может возникнуть барьер, который он уже не сможет преодолеть даже тогда, когда ему нужно будет пожертвовать безопасностью в угоду эффективности и использовать структуры в своем коде.
Статические конструкторы являются одной из самых странных возможностей C# и CLR и многие годы я не понимал их достаточно хорошо, но поскольку Джон (Скит) внес дополнительные разъяснения в мое понимание этой возможности, я все еще явно не до конца ее понимаю!
Эрик Липперт “Static constructors, part three”
Вопрос: в каком порядке будут вызваны экземплярные и статические конструкторы классов B и D при создании экземпляра класса D?
class B { }
class D : B { }
Ответ: конструкторы экземпляров вызываются от базового к наследнику, а статические конструкторы – it depends!
Поскольку в Гугл+ так и не нашлось объяснения странного поведения приведенного там кода, то я решил рассказать об этом более подробно.
Итак, вопрос заключается в следующем: что мы ожидаем увидеть при исполнении следующего кода и что мы увидим на самом деле?
class CrazyType
{
public static readonly int Foo = GetFoo();
private static int GetFoo()
{
return Task.Run(() => 42).Result;
}
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Main method get called!");
Console.WriteLine(CrazyType.Foo);
}
}
«При наличии общего механизма перегрузки функций аргументы по умолчанию становятся логически избыточными и в лучшем случае обеспечивают небольшое удобство нотации»
Б. Страуструп «Дизайн и эволюция С++»
Многие разработчики, перешедшие в .NET с языка С++ хотели увидеть в C# аргументы по умолчанию. И вот в C# 4.0 они появились, но с существенными ограничениями, особенно по сравнению с языком С++. Конечно эти особенности и ограничения не сложно запомнить, а их перечисление займет не больше пары строк, но вместо простого перечисления этих особенностей я предлагаю побывать в шкуре разработчиков этой фичи для языка платформы .NET и прийти к этим ограничениям и особенностям самостоятельно.
Поскольку мне говорят (точнее пишут), что я немного утомил с философией программирования и стоит браться за ум вспомнить и о технологиях, то я решил не откладывать это дело в долгий ящик, и опубликовать несколько заметок о языке C#. Тем более, что после подготовки к Hot Code остались некоторые наработки, которыми будет интересно поделиться.
Итак, у нас есть структура BigDouble с оператором неявного приведения типов к double и список этих структур:
struct BigDouble
{
private readonly double _value;
public BigDouble(double value) { _value = value; }
public static implicit operator double(BigDouble value)
{ return value._value; }
}
var bigDoubles = new List<BigDouble>
{
new BigDouble(42.0),
new BigDouble(18.0),
};
foreach (double d in bigDoubles)
{
Console.WriteLine(d);
}
var query = from double d in bigDoubles
select d;
foreach (var d in query) { Console.WriteLine(d); }
(Картинка без намека, просто уж очень хотелось котика в статью добавить! Ведь это основной залог популярности в интернетах, правда? :))
У меня очень неоднозначное отношение к книгам Роберта Мартина… В них довольно много здравых и интересных мыслей, но иногда они выражаются столь категорично, что неокрепшим программерским мозгом они могут восприниматься неправильно. Если же мозг читателя достаточно окреп, чтобы воспринимать советы прагматично, то есть все шансы, что ничего нового из этих советов он (мозг или программист) не вынесет.
В прошлый раз мы рассмотрели основные подходы к комментированию кода, а в этот раз я хочу рассмотреть эти советы на простых практических примерах.
Основные претензии к комментариям заключаются в том, что они устаревают или просто дублируют код, описывая его на том же уровне абстракции, что и сам код. Ниже представлен утрированный антипаттерн:
"Не стоит относиться к комментариям как к "абсолютному добру". На самом деле, комментарии в лучшем случае являются неизбежным злом. Если бы языки программирования были достаточно выразительными или если бы мы умели искусно пользоваться этими языками для выражения своих намерений, то потребность в комментариях резко снизилась бы, а может быть и вовсе сошла "на нет".
Роберт Мартин "Чистый код"
"Комментарии должны сообщать о коде что-то такое, что он не может сообщить он сам – в виде заключения или в виде намерений".
Стив Макконнелл "Совершенный код"
В комментариях к предыдущей заметке был задан такой вопрос:
«Вот есть, сккажем, класс, который читает какой-нибудь файл и потом его анализирует. Как такое тестировать?
Неужели надо вынести код чтения файла в отдельный класс, создать интерфейс и передать экземпляр через конструктор? Боюсь, если так буду делать, то не закончу и половины вовремя.»
Здесь очень мало информации, поэтому все мои рассуждения можно использовать лишь в качестве отправной точки дизайна и реализации. Любой исходный дизайн эволюционирует по мере развития требований и понимания задачи, но определенные подходы применимы даже при таком наборе «входных данных».
В комментариях к одной из заметок в Г+ мне предложили рассказать о тестировании закрытых методов. Поскольку это интересная тема, то в сегодня я постараюсь ответить на этот вопрос.
Q: - Как тестировать закрытые методы?
A: - Напрямую – никак!
Ну а теперь давайте поговорим об этом более подробно.
Многие мыслители сходятся на том, что главной целью дизайна является борьба со сложностью. Разбиение приложения на слои, переход от наследования к агрегации, создание приложения из хорошо работающих и проверенных блоков более низкого уровня, все это позволяет смягчить неотъемлемую сложность системы и свести случайную (или привнесенную) сложность к минимуму.
DISCLAIMER: данную статью можно рассматривать, как дополнительные материалы к моему выступлению на MS SWIT с темой “Design for Testability: mocks, stubs, refactoring”.
В предыдущей заметке мы более внимательно рассмотрели принцип инверсии зависимостей, но при этом вопросы о том, как же добиться тестируемого дизайна и не наплодить бесконечное количество интерфейсов, остались открытыми.
В этой заметке я хочу показать типичный пример выделения интерфейсов для получения тестируемого дизайна и рассмотреть разницу между хорошим дизайном и тестируемым дизайном.
В языке C# существует возможность расширять существующие типы методами расширения, синтаксис вызовов которых похож на вызов экземплярных методов. На этом построен весь LINQ, да и в обычной жизни методам расширения находится полезное применение.
F# также поддерживает возможность расширения существующих типов, но принцип работы и логика этого всего дела несколько иная. В F# не существует таких понятий, как методы расширения, свойства расширения и т.п., вместо этого существует общее понятие под названием "расширение типов" (type extension). Причем под этим термином подразумевает два разных явления: intrinsic extensions ("внутренние расширения") и optional extensions ("необязательные расширения").
И хотя синтаксис расширений совершенно одинаковый, семантика у них принципиально разная. Intrinsic extensions – это аналог частичных типов в C#, а optional extensions – аналог методов расширения, но в более расширенном виде, поскольку мы можем добавить в существующий тип не только «экземплярные» методы, но и статические методы, свойства или события.
DISCLAIMER: У автора этой статьи нет цели подорвать авторитет или каким-то образом обидеть столь уважаемого камрада, как «дядюшка» Боб Мартин. Речь здесь идет скорее о более тщательном обдумывании принципа инверсии зависимостей и анализ примеров, использованных при его описании.
Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) был впервые описан Бобом Мартином в одноименной статье, опубликованной в журнале C++ Report в 1996 году. Затем, практически в неизменном виде он был опубликован в книгах Боба Мартина «Принципы, паттерны и методики гибкой разработки» [Mattin2006].
По ходу статьи я буду приводить все необходимые цитаты и примеры из вышеупомянутых источников. Но чтобы не было «спойлеров» и ваше мнение оставалось объективным, я бы рекомендовал потратить 10-15 минут и ознакомиться с оригинальным описанием этого принципа в статье [Martin96] или книге [Martin96].
У блогов вообще и любой другой информации в интернетах в частности есть одна особенность, что время жизни этой информации очень мало. Интерес к хорошей статье быстро возникает и также быстро пропадает, в результате оказывается очень просто пропустить интересные вещи, опубликованные пару недель, месяцев или же лет назад.
У того же Эрика Липперта есть десятки потрясающих постов, к которым можно возвращаться время от времени, но поскольку они редко всплывают на поверхность, то о них мало кто знает и помнит. В некотором роде, мое сообщение на rsdn-е под названием «Wanted! Старые хиты Эрика Липперта» можно считать нулевым выпуском этой серии постов, которую я планирую публиковать каждый месяц.
Сервис локатор – это очень неоднозначный паттерн проектирования. С одной стороны, именно с его появлением началось активное развитие DI контейнеров и практик инверсии управления. С другой стороны, именно благодаря повсеместному использованию сервис локаторов в приложениях техники управления зависимостями получили и продолжают получать столько критики.
Но прежде чем переходить к описанию достоинств и недостатков этого паттерна, давайте дадим его описание и общую структуру.
Во-первых, я внимательно подхожу к выбору книг. К сожалению (или счастью), сейчас о программировании выходят десятки книг в месяц и далеко не каждая из них достойна нашего с вами внимания. В любой области, от алгоритмов до управления проектами, есть классические книги, поэтому для начала я нахожу наиболее интересный и авторитетный источник, а не бросаюсь на первую попавшуюся мне книгу.
На примере кода Боба Мартина из его книги «Принципы, паттерны и методики гибкой разработки»
Наличие в книгах ошибок дело совсем не новое, но данный случай немного особый. Во-первых, речь идет о книге, в которой, по словам автора, "именно код и является сутью этой книги", а во-вторых, подобные ошибки являются относительно простыми и показательными, чтобы мы с вами их не допускали в своих проектах.
Описывая TDD Боб Мартин пишет о том, что TDD – это не просто вначале тесты, а потом код, это способ обдумывания дизайна класса через призму тестов, что делает его более обдуманным и слабосвязанным. Этот подход вполне оправдан и юнит тесты и правда являются отличной лакмусовой бумажкой качественного дизайна.
Обсуждая практические аспекты управления зависимостями я говорил о том, что суть инверсии зависимостей заключается в том, что мы не хотим захламлять текущий класс лишними деталями, поэтому перекладываем их на более высокий уровень.
Интуитивно понятно, что в этом случае мы не избавляемся от зависимостей, а лишь перемещаем проблему из одного места в другое. Насколько этот подход разумен? Почему зависимости в одном месте влекут к проблемам сопровождаемости, а зависимости в другом месте безвредны?
В большинстве приложений оптимизации, о которых я писал в прошлый раз, совершенно неинтересны: будет ли экземпляр делегата создаваться каждый раз или он будет создаваться лишь первый раз и сохраняться в кэше. Но в таких проектах, как РеШарпер, Visual Studio или компилятор, этому придается важное значение, поэтому не удивительно, что во многих сессиях вопросы эффективности так или иначе затрагиваются.
Я не могу сказать, что такое же внимание к эффективности требуется для “обычных” проектов, тем не менее, понимание того, что происходит за кулисами может помочь тогда, когда в этом появится необходимость. Вот на парочке подобных примеров я и хочу остановиться.
В этом году я первый раз попал на MVP Summit, который ежегодно проводит Майкрософт для своих MVP. Он длится 3 дня и многое, что на нем рассказывается попадает под NDA (Non-Disclosure Agreement) и разглашению не подлежит. Но помимо закрытой информации, тут сами MVP делятся друг с другом полезными советами, да и то, что рассказывают сотрудники МС-а довольно часто доступно публично.
Сегодня никакой особой программы не было, помимо регистрации и стартового мероприятия (знакомства всех со всеми), но для dev подразделения было сделано небольшое исключение в виде QA-сессии со Стивеном Таубом (Stephen Toub) и Lucian Wischik (даже не буду пытаться транслитить). Это была чистейшей воды ad hoc сессия на которой обсуждали практически любые вопросы, связанные с асинхронностью и не только (даже успели потролить на тему Ambient Context vs Dependency Injection).
Сегодня мы переходим к самому простому паттерну передачи зависимостей – передаче через аргументы метода, Method Injection.
Существует две разновидности паттерна под названием Method Injection. В некоторых случаях под этим паттерном понимается установка зависимостей объекта с помощью вызова метода:
Открывая книгу по «новомодной технике проектирования», такой как инверсия зависимостей ожидаешь увидеть описание очередной серебряной пули. Дескать, вот, до этого все мы жили неправильно, а теперь, вооружившись ломом контейнером и какой-то матерью мы сможем писать новые приложения за 10 минут.
Поскольку сам я к подобным новомодным инструментам отношусь с некоторой осторожностью, то я был приятно удивлен тем, что в книге Марк делает акцент на общепринятых практиках проектирования, роли стандартных паттернов проектирования, да и вообще, рассматривает принципы управления зависимостями в отрыве от конкретных инструментов.
Наверняка многие слышали о принципе инверсии зависимостей, букве D из аббревиатуры SOLID. Изначально этот принцип был описан Бобом Мартином еще в 1996 году в статье для C++ Report. Затем эта же статья в расширенном виде вошла в книги «дядюшки» Боба “Agile Software Development, Principles, Patterns and Practices” и затем в “Agile Principles, Patterns and Practices in C#”.
В исходной статье Боба Мартина есть 3 части: философские размышления о хорошем и плохом дизайне, описание принципа инверсии зависимости и «простой пример» с лампочками и кнопками. Вторая часть статьи весьма известна, последняя – малоинтересна, а вот первую часть, ИМХО, незаслуженно обходят вниманием.
При обсуждении прошлой заметки в Г+ был задан вопрос о том, как избежать передачи самого контейнера в конкретные классы и ограничить распространение библиотеки управления зависимостями минимальным количеством мест. Я все равно думал раскрыть эту тему, а раз так, то почему бы не сделать этого сейчас.
Суть инверсии зависимостей сводится к тому, что класс перекладывает ответственность за создание зависимости или получение ее экземпляра на более высокий уровень, в результате чего, он сам не создает экземпляр конкретного класса, а получает его от более высокоуровневого кода через конструктор или свойство. В результате, мы заменяем композицию агрегацией и перекладываем часть проблем с текущего класса куда-то выше.
Возвращаемся к теме управления зависимостями, заброшенными на некоторое время.
Еще одним достаточно популярным паттерном внедрения зависимостей является Property Injection, который заключается в передаче нужных зависимостей через “setter” свойства. Все современные DI-контейнеры в той или иной мере поддерживают этот паттерн, что делает его использование достаточно простым. Я рекомендую быть осторожным с этим паттерном, поскольку с точки дизайна передача зависимостей через свойства усложняет использование, понимание и поддержку.
Но давайте обо всем по порядку.
Я был уже готов продолжить цикл статей, посвященных управлению зависимостями, но на днях наткнулся на очень любопытную статью и не смог пройти мимо нее без комментариев.
Я иногда почитываю dzone и периодически нахожу там довольно интересные статьи, и вот вчера, в разделе "Popular on DZone" наткнулся на любопытную статью под названием “8 Most common mistakes C# developers make”.
Я предлагаю вначале полистать вам ее самому, а уже потом смотреть мои комментарии.
Мне очень запомнился один момент, который произошел уже без малого 10 лет назад. Я только пошел на свою первую работу и проработал там несколько месяцев; в перерыве между парами мы стояли с моим другом в коридоре и я оживленно рассказывал о чем-то, что я недавно узнал благодаря первым шагам в мире разработки ПО. Мой друг к тому времени уже проработал года полтора или два и сказал мне: «Ничего, Серега. Пройдет еще годик другой и твое отношение к этому делу изменится». С того памятного для меня разговора прошло почти десять лет, а меня так и не «попустило»; мои интересы в области программирования, меняются, но сам интерес остается неизменным.
