Обзор книги Dependency Injection in .NET

Dependency Injection in .NET

Книга написана в 2011 году, Марком Симаном(Mark Seemann). Дошёл я до неё весьма просто: в какой-то момент времени мне стало неуютно писать модульные тесты, и к тому моменту я уже кое-что слышал о внедрении зависимостей(dependecy injection), а учитывая то, что это, наверное, наиболее популярная книга по ВЗ — я и выбрал её для прочтения.

Язык книги ничем на фоне других технических книг не выделяется,— всё довольно просто, без академической сухости и художественной сложности. Единственно, что для меня было тяжело — это читать аналогии, которые автор приводил: начиная новую главу, объясняя новую тему, автор всё сравнивал с приготовлением соуса. Я не знаю почему, но меня это жутко раздражало и не способствовало понимаю. Конечно, это, на мой взгляд, лучше чем набившие оскомины примеры из финансового сектора(чем грешат почти все технические книги, что я читал), но всё равно примеры не очень вдохновляющие.

Другим минусом, продолжая тему стиля написания, для меня явилось именование классов в примерах, которые автор приводит. Хотя примеры и просты, лично я неоднократно путался во всех этих «Service, System, Management, Product» — это настолько общие имена, которые в голове никак не хотят удерживаться. На мой взгляд, когда область применения имени растягивается на много страниц, то куда лучше придумать ёмкое и запоминающееся имя, чем плодить эти серые RespositoryManagerController и т.п. Чем-то мне это напоминает какой-нибудь РосГазХранНефтьТехСбыт — невозможно запомнить.

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

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

Покончив с минусами, давайте поговорим о том, что же всё-таки содержится в книге. Книга состоит из 520+ страниц и, я полагаю, Вы догадываетесь, что каким бы классным и важным не был паттерн внедрения зависимостей, 500 страниц о нём говорить не смог бы и сам Лев Толстой. Поэтому, в целом, для понимания, что же это за паттерн, а также как с ним работать достаточно первых 3 глав, которые умещаются на 100 страниц. Но что же, остальной материал бесполезен? Конечно нет, дальше, в главе 4 читатель знакомится с базовыми сценариями внедрения зависимостей посредством различных методов(через конструктор, свойство, метод и т.д), потом автор показывает нам как делать не надо, как некоторые техники, которые могут быть похожи на паттерн ВЗ, не являются оным, а являются антипаттернами. Наконец, поговорив о том как делать надо и как делать не надо, автор представляет нам несколько техник рефакторинга, которые помогают сделать код с зависимостями проще.

Затем идёт часть, которая начинается с главы посвящённой базовым сценариям добавления паттерна ВЗ в популярные приложения на .NET: WPF, WCF, ASP .NET и т.д. После этого идут две главы посвящённые управлению временем жизни зависимостей, а также ещё парочке паттернов, которые автор решил включить в книгу.

Заканчивается книга(больше 200 страниц!) частью, посвящённой существующим контейнерам, которые облегчают внедрение зависимостей в коде; рассматриваются следующие контейнеры: Castle Windsor, StructureMap, Spring .NET, Autofac, Unity и MEF. Рассмотрение контейнера заключается в том, что автор показывает читателю как те идеи, что были рассмотрены до этого, могут быть реализованы тем или иным контейнером. Я не читал все эти главы, т.к. эти контейнеры мне не интересны(я в результате выбрал Simple Injector, не потому, что я провёл сравнительный анализ, а просто он мне на душу лёг).

Итак, кратко пробежавшись по содержанию книги, я хочу добавить, что в целом книга посвящена ослаблению зависимостей в коде, а не только непосредственно техникам внедрения оных. Именно поэтому, я считаю, что книга является отличным вариантом для повышения своих навыков, как проектировщика. Но книга уже подразумевает некоторый опыт в разработке, она не предназначена для новичков. С моей точки зрения, её стоит читать людям, которые уже набили шишек в написании программ и ищут как улучшить свой навык. Особенно полезна это книга будет тем, кто пишет модульные тесты(unit tests), т.к. хотя техника внедрения зависимостей и не является прямым следствием моды на модульное тестирование(что неоднократно повторяет сам автор — ВЗ это не только для упрощения тестов), она просто невероятно облегчает написание тестов. Лично я самостоятельно дошёл до того, что в книге называется «poor man’s DI», а чтение книги позволило мне структурировать весь тот хаос, что был в голове и перейти к более современным технологиям для работы с зависимостями.

Теперь, что касается .NET в заголовке: будет ли полезна эта книга тем, кто не пишет на .NET? Я считаю, что да,— она будет полезна. Никаких сложных C# конструкций в книге нет, чтобы человек не знакомый с ним не смог их понять. Единственно, что может стать препятствием так это то, что в книге автор приводит примеры внедрения техники ВЗ через WPF, WCF и т.п. приложения. Я думаю, что человеку, не знакомому с этими типами приложений, будет не очень легко разобраться во всех примерах; вообще, на мой взгляд, примеры являются слабой стороной книги, а вот теория просто замечательная.

Исходя из всего вышесказанного, я рекомендую эту книгу к прочтению всем разработчикам, которые пишут на императивных языках, имеющие опыт в создании хотя бы какой-то мало-мальски сложной архитектуры, которые хотят получить инъекцию структуру в тот хаос, что творится в голове. С другой стороны, я не рекомендую её новичкам — скорее всего вы там мало что поймёте, и этот материал будет для вас, пока, бесполезен.