Книга Р. С. Мартина и М. Мартина «Принципы, паттерны и методики гибкой разработки на языке C#»

Agile_C#_cover.inddНа днях дочитал книгу двух Мартинов (Роберта и Мики) «Принципы, паттерны и методики гибкой разработки на языке C#». Очень стоящая книга, охватывающая все этапы проектирования софта. Несмотря на то, что в названии фигурирует C#, и все примеры действительно написаны на нем, книгу можно (нужно) читать всем, кто занимается программированием и проектированием. К языку C# описание никак не привязано. Более того, в книге открытым текстом сказано, что изначально некоторые примеры были написаны на C++ или Java, а затем для книги переписаны на C#.

В книге описываются все этапы проектирования с учетом того, как эти этапы выполняются при так называемой «гибкой разработке». Честно говоря, я не очень глубоко разбирался в идеологии экстремального программирования (XP), но описываемая в книге гибкая разработка очень ее напоминает (и авторы ссылаются на XP): здесь и парное программирование, когда за одной клавиатурой сидят двое (у нас было такое в школе, когда не хватало на всех компьютеров 🙂 ), и программирование через тесты (сначала пишутся тесты, потом под них пишется код), и частый выпуск промежуточных работающих версий программы, и утверждение о том, что лучшая документация — это код.

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

В книгу включена одна интересная глава, которая в оригинале была оформлена в виде статьи. Эта глава описывает процесс проектирования и кодирования (эти два процесса перемешаны) программы для подсчета очков при игре в боулинг. Эту главу нужно обязательно показывать тем, кто хочет понять что из себя представляет проектирование софта, а особенно стоит показать начальству, чтобы оно прониклось как происходит рождение программы, и что написание программы — это не просто кодирование в императивном стиле (a la Pascal, Fortran и т.п.).

Несколько глав посвящено основным принципам, которых необходимо придерживаться при проектировании объектно-ориентировании систем, каждому принципу посвящена отдельная глава (пусть и небольшая).

  • Принцип единственной обязанности, который выражается так: «У класса должна быть только одна причина для изменения». Обычно этот принцип формулируют в виде, что класс должен выполнять только одну операцию, но авторам их формулировка кажется более точной.
  • Принцип открытости/закрытости: «Программные сущности (классы, модули, функции и т.п.) должны быть открыты для расширения, но закрыты для модификации». То есть необходимо стремиться проектировать систему так, чтобы при добавлении новых функций нужно было бы только дописывать новый код, но не изменять старый.
  • Принцип подстановки Лисков: «Должна быть возможность вместо базового типа подставить любой его подтип». Кажется, что этот принцип обеспечивается компилятором, но на практике случаются ситуации, когда не любой производный класс можно передать в функцию, который ожидает базовый класс. Таких ситуаций надо избегать.
  • Принцип инверсии зависимости. «1. Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций. 2. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций». Этот принцип противоположен принципам, которые использовались в доисторические времена императивного программирования, когда высокоуровневые функции зависели от реализации какой-либо низкоуровневой библиотеки, и при изменениях в низкоуровневой библиотеке приходилось переписывать высокоуровневым функции.
  • Принцип разделения интерфейсов. Этот принцип близок к принципу единственной обязанности, но применительно к интерфейсам.

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

Еще несколько глав посвящены UML. Честно говоря, чтение книг и статей про UML у меня всегда вызывало сонливость. Я так полностью и не осилил казалось бы небольшую книгу Буча, Рамбо и Джекобсона «UML. Руководство пользователя», прочитав там только интересующие меня главы. Мартины же выкинули из описания UML всякую «бюрократию» и оставили только то, что нужно знать программисту, а не менеджеру, рисующему красивые картинки перед заказчиком. Почти все диаграммы здесь подкрепляются кодом. В итоге получилось довольно хорошее описание UML. Странно только, что эти главы расположены в середине книги, а к этому времени авторы уже активно используют UML.

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

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

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

Паттерны в книге описаны не так сухо, как в книге Банды Четырех (для тех, кто не знает, «Приемы объектно-ориентированного проектирования. Паттерны проектирования», Гамма, Хелм, Джонсон и Влиссидес) и поясняются очень хорошими примерами. Несмотря на то, что авторы постоянно ссылаются на вышеуказанную книгу, я бы советовал новичкам сначала прочить все-таки книгу Мартинов — здесь паттерны описаны более доходчиво. Причем, авторы подошли к изложению творчески, иногда паттерны в главах рождаются в результате рефакторинга какой-то уже существующей структуры классов.

В приложениях приводятся две статьи, одна из них Джека Ривса с его взглядом на проектирование в далеком 1992 году с комментариями от 2002, и одна, судя по всему, самих авторов, в которой сравниваются две компании — раздолбайско-бюрократической и идеально следующая принципам гибкой разработки. В самой статье после прочтения книги ничего нового не будет, но сатирическое описание бюрократической компании повышает настроение.

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

Эту книгу нужно читать и новичкам сразу после изучения какого-либо объектно-ориентированного языка, чтобы они поняли, что из себя представляет проектирование и зачем это нужно. Вообще, я бы теперь составил следующую очередность чтения книг про проектирование:

  1. Мартины «Принципы, паттерны и методики гибкой разработки на языке C#».
  2. Гамма, Хелм, Джонсон и Влиссидес «Приемы объектно-ориентированного проектирования. Паттерны проектирования».
  3. Фаулер «Рефакторинг. Улучшение существующего кода».
  4. Кериевски «Рефакторинг с использованием шаблонов».

В заключении хочу предупредить, что у книги значится издание 2010, но это просто исправленное издание на русском языке (говорят к прошлому изданию были большие претензии по поводу перевода), оригинал вышел не то в 2005, не то в 2006 году.

Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.

Пожалуйста, оцените запись

УжасноПлохоТак себеХорошоОтлично (Количество голосов: 4, средняя оценка: 5,00)
Загрузка...

комментариев 9

  1. kostyl:

    Ну так а в чём изюминка, или это очередная книга про принципы, которые уже 20 лет известны?

  2. Jenyay:

    Каких-то особых откровений в книге может и нет, но мне понравилось то, что здесь вместе собрано все, что касается проектирования: сами принципы проектирования (кстати, внятного их описания я до этого не встречал в одной книге), UML, паттерны, общая организация работы программистов.

  3. Vladimir:

    Привет, а ссылку на электронный вариант не скинешь ? а то что то в нете не могу найти(если конечно ты сам не покупал)

  4. Jenyay:

    Я ее в бумаге читал.

  5. Vladimir:

    ясно, спс , а за сколько покупал если не секрет и где ?

  6. Jenyay:

    Покупал на books.ru, примерно рублей на 150-200 дешевле, чем она у них стоит сейчас, потому что заказывал еще до того, как она у них появилась в наличии.

  7. Electriq:

    Заинтриговал, надо почитать 🙂
    А ты «Чистый код» Роберта Мартина читал? Я его до конца никак не одолею, но уже прочитанное мне понравилось. Да, это в основном не откровение, а свод старых умных мыслей. Полезность подобных книг в том, что они акцентируют внимание на том, о чем можно просто не думать.
    Кстати, Books.ru — это магазин питерского издателства Символ Плюс, потому их книги там дешевле.

  8. Jenyay:

    > А ты «Чистый код» Роберта Мартина читал?

    На «Чистый код» постоянно натыкался, но все никак не соберусь почитать.

    > Кстати, Books.ru – это магазин питерского издателства Символ Плюс, потому их книги там дешевле.

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

  9. dvapelnik:

    господа, ищу эту книгу в электронном варианте. ниукого не завалялось электронного экземпляра? хотелось бы почитать именно в срезе C#
    если у кого всё же есть — прошу закинуть мне на почту, буду очень признателен за это
    dvapelnik@gmail.com

Leave a comment

Subscribe without commenting