понедельник, 14 июля 2014 г.

Книги по дизайну и ООП

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

Невозможно стать хорошим архитектором прочитав несколько книг, поскольку нужно четко понимать, как конкретное теоретическое решение отражается в реальных системах. Я никак не могу помочь вам с практикой, но могу посоветовать хорошую литературу в области ООП/ООД/ФП.

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

Что главное для вас в дизайне приложений? Для меня самым сложным в дизайне и разработки реальных приложений является борьба со сложностью (pun intended;)), из которого уже вытекают все остальные проблемы. Все вопросы сопровождаемости, качества дизайна, расширяемости и т.п. отходят на второй план, если вы не можете справиться "привнесенной сложностью" (accidental complexity) и как-то ограничить естественную сложность (essential complexity).

«Звезда в преддверии коллапса; ребенок, который учится читать; клетки крови, атакующие вирус, - это только некоторые из потрясающе сложных объектов физического мира. Компьютерные программы тоже бывают сложными, однако их сложность совершенно другого рода. … Эйнштейн утверждал, что должны существовать простые объяснения природных процессов, так как Бог не действует из каприза или по произволу. У программиста нет такого утешения: сложность, с которой он должен справиться, лежит в самой природе системы».

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

ОК, хватит философствовать, давайте перейдем к конкретным книгам.

С чего начать?

С чего начинать изучение ООП и принципов проектирования, если у вас толком нет опыта в программировании? Я бы рекомендовал начинать с книги Фриманов "Паттерны проектирования" (Head First Design Patterns). Несмотря на "желтоватое" название, книга и правда очень хороша (это одна из самых "рейтинговых" книг на amazon.com!). В ней в полу-игровой форме дается описание паттернов проектирования, но через призму фундаментальных принципов проектирования вообще и ООП в частности. Поэтому если новичок в программировании или ООП спрашивает у вас о хорошей книге по этой теме, то книга Фриманов – это именно то, что нужно.

Если нужно что-то чуть более продвинутое и, наверное, более философское, то я обычно предлагаю прочитать первые две части книги Гради Буча. Не факт, что она окажет такое же серьезное влияние на вас, какое она оказала на меня, но там даются фундаментальные понятия ООП и важные этапы и принципы разработки ПО, такие как борьба со сложностью. Эти двести страниц вполне могут изменить ваш взгляд на разработку ПО, так почему бы не попробовать?;)

Для продвинутых

Давайте рассмотрим более интересный случай: у вас уже есть опыт в 3-5 лет, но внезапно вы поняли, что хотите расти дальше (в архитекторы и прочие «синьеры») и текущих знаний в области ООП и проектирования в целом, вам не хватает.

Тут я бы посоветовал взять одну из фундаментальных книг, представленных ниже, типа Мейера или Лармана и разбавить их чтение чем-то попроще: например, "Рефакторингом" Фаулера или одной из книг по DDD (также не стоит забывать о книгах по юнит-тестированию, в которых обычно очень хорошо покрыты темы дизайна). Вообще, я бы рекомендовал читать как минимум одну книгу по дизайну в год, чтобы полученный практический опыт соответствовал текущим теоретическим знаниям.

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

Фундаментальные труды

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

Оригинал второго издания книги Мейера вышел 19 (!) лет назад, книга Эванса по DDD – 11, книга Лармана – 10, но каждая из них абсолютно актуальна. Да, некоторые "философские" рассуждения автора показывают их почтенный возраст, но это нисколько не уменьшает их ценность.

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

Если говорить о лучшей книге по ООП, то нет ничего лучше труда Мейера. Я ее рекомендую всем и каждому, но, видимо, 1.5 тысячи страниц немного отбивают охоту. Если книга Мейера кажется перебором, то подойдут другие книги из этого списка: книги Буча или Лармана.

Бертран Мейер, Объектно-ориентированное конструированию программных систем, 1995, 2-е издание

clip_image002[6]

Книга, которую многие по своей фундаментальности в области объектно-ориентированного программирования сравнивают с творением Дональда Кнута (причем совершенно без преувеличения) в области алгоритмов и структур данных. Эта книга является наиболее фундаментальным трудом по объектной парадигме, когда-либо выходивших на русском или на английском языках. Книга охватывает широкий круг вопросов, начиная от вопросов наследование, инкапсуляция, модульности, повторного использования, заканчивая автоматическим управлением памятью, шаблонами проектирования и проектированием по контракту (который только спустя два десятилетия начинает набирать обороты в mainstream языках и технологиях).
Лучшая книга по ОО-технологиям ever!

Дополнительные ссылки: рецензия, amazon.com, ozon.ru (ru)

 

Крэг Ларман, Применение UML 2.0 и шаблонов проектирования, 3-е издание, 2004

clip_image004[6]

Еще один учебник по разработке ПО с уклоном в объектно-ориентированные методы: анализ и проектирование.

Дополнительные ссылки: amazon.com, ozon.ru (ru)

 

 

 

 

 

 

Гради Буч, Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е издание, 2007

clip_image006[6]

Еще одна классическая книга по объектно-ориентированному программированию, но в отличие от книги Бертрана Мейера имеет менее формальный и более описательный характер. В книге потрясающе описана проблема сложности ПО, описаны роли абстракции и иерархии, описаны наиболее популярные на сегодняшний день методологии разработки, и многое другое.

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

Дополнительные ссылки: рецензия, amazon.com, ozon.ru (ru)

 

 

 

Книги по DDD

Многие ассоциируют DDD со всякими новомодными штучками, типа Event Sourcing, CQRS или, на худой конец, с рядом enterprise-паттернов и обязательным выделением сборок "Domain" и "DataAccess". На самом деле, основная цель любого вида проектирования заключается в моделировании предметной области, и любая книга по ООП или ФП говорит о том, как создавать модели, наиболее близкие к реальному миру.

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

Если же говорить о книгах по DDD, то тут есть два классических труда: «Blue Book» Эванса и “Red Book” Вернона. Обе книги очень хороши и рассматривают не только конкретные DDD-паттерны, но и их связь с принципами проектирования и классическими паттернами. Выбирайте любую из них, а затем через годик возьмитесь за другую!

Эрик Эванс, Предметно-ориентированное проектирование, 2003

clip_image008[6]

Дополнительные ссылки: рецензия, amazon.com, ozon.ru (ru)

Vaughn Vernon, Implementing Domain-Driven Design, 2013

clip_image010[6]

Дополнительные ссылки: amazon.com

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

Многие книги, представленные ранее, в той или иной мере касаются темы паттернов проектирования (Design Patterns). Некоторые из них (например, книга Лармана) касаются классических паттернов проектирования, другие (например, книга Эванса) описывают более специфические паттерны.

Если говорить об изучении паттернов проектирования, то тут как нельзя лучше подойдет итеративный подход. Проще всего начать с хорошего учебника – "Head-First Design Patterns", и через время снова вернуться к этой теме, и взяться уже за классическую книгу "банды четырех", акцентируя свое внимание на разделах по анализу и применимости паттернов проектирования.

Эрих Гамма и др., Приемы объектно-ориентированного проектирования, 1994

clip_image012[6]

Это та самая, знаменитая книга «банды четырех», после выхода которой началось стремительное развитие идеи шаблонов проектирования в мире разработки ПО. После ее выхода идея шаблонов начала распространяться и развиваться, и сегодня идеи шаблонов применяется не только в контексте проектирования, а и практически в каждой области разработки программного обеспечения.

Дополнительные ссылки: рецензия, amazon.com, ozon.ru (ru)

 

 

 

 

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

clip_image014[6]

Лучший учебник по ООП, паттернам и принципа проектирования. Несмотря на "желтоватое" название (Head-First Design Patterns), книга действительно очень хороша: темы рассмотрены в игровой форме и при этом акцент делается не на конкретных паттернах, а на принципах проектирования и их связи с паттернами.

Дополнительные ссылки: рецензия, amazon.com, ozon.ru (ru)

 

 

 

 

Юнит-тестирование и сопровождение

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

ПРИМЕЧАНИЕ
Если интересно мое мнение о юинт-тестировании, то можно начать с соответствующего раздела в моих статьях.

В данном разделе представлены книги двух категорий: во-первых, это книги о юнит-тестировании, такие как книга Кента Бека о TDD, или книга Роя Ошерова. В них описываются инструменты юнит-тестирования, тестовые паттерны, а также их влияние на дизайн. Каждая из этих книг очень хороша, и они скорее дополняют друг друга, а не противоречат.

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

Каждая из книг в этом разделе будет полезна любому программисту с парой лет опыта.

Kent Beck, Test-Driven Development: By Example, 2002

clip_image016[6]

Возрастная книга, но если вы хотите понять, что же такое TDD с точки зрения его автора, то лучшего источника не найти. Книга легко читается, в ней довольно много практических примеров, и она не слишком устарела несмотря на свой возраст.
Если хотите получить взвешенное мнение о TDD, то без этой книги не обойтись.

Дополнительные ссылки: amazon.com, ozon.ru (ru)

 

 

 

 

Steve Freeman, Nat Pryce, Growing Object-Oriented Software Guided by Tests, 2009

clip_image018[6]

Одна из лучших книг для изучения TDD вообще, и тестированию, в частности. Отлично описан процесс "выращивания" системы, ее эволюция и адаптация под новые требования. Хорошо описана связь тестов и дизайна. Must Read!

Дополнительные ссылки: рецензия, amazon.com

 

 

 

 

 

Roy Osherove, The Art of Unit Testing: with examples in C#, 2014

clip_image020[6]

Паттерны не ограничиваются классическими паттернами, описанными в книге банды четырех. Паттерны повсюду: есть архитектурные паттерны, есть паттерны проектирования, есть DI-паттерны, есть DDD паттерны, есть паттерны рефакторинга, есть даже паттерны поведения. Точно также существуют паттерны разработки юнит-тестов. Есть типовые подходы к организации тестового кода для решения тех или иных задач. Лучшим источником по этой теме является фундаментальный труд "xUnit Test Patterns: Refactoring Test Code", а книга Роя является отличной книгой по этой же тематике в контексте платформы .NET.

Дополнительные ссылки: рецензия, amazon.com, ozon.ru (ru)

 

 

 

Мартин Фаулер, Рефакторинг. Улучшение существующего кода, 1999

clip_image022[6]

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

Дополнительные ссылки: amazon.com, ozon.ru (ru)

 

 

 

 

Майкл Физерс. Эффективная работа с унаследованным кодом, 2004

clip_image024[6]

Лучшая книга на рынке с перечнем подходов к работе с унаследованным кодом. Здесь описаны как вопросы качества кода, подходы к юнит-тестированию и проблемы модификации кода без тестов. Must Read!

Дополнительные ссылки: amazon.com, ozon.ru (ru)

 

 

 

 

 

Проектирование в контексте платформы .NET

Большая часть представленных здесь книг, не привязаны к конкретной платформе. В некоторых из них используются примеры на Java, в других –C#, но описанные в них идеи будут полезны любому разработчику.

В этом разделе представлены две книги, которые будут более полезными для .NET разработчиков, чем для кого-то другого. Во-первых, это классическая книга Квалины и Абрамса – “Framework Design Guidelines”, которая необходима всем, кто занимается разработкой повторноиспользуемых компонентов на платформе .NET. И во-вторых, это замечательная книга Марка Сиимана – "Dependency Injection in .NET", в этой книге рассмотрены различные DI-паттерны, и их влияние на создание современных .NET-приложений.

Krzysztof Cwalina and Brad Abrams, Framework Design Guidelines, 2009

clip_image026[6]

Разработка качественных систем является весьма сложной задачей, а разработка качественных библиотек (особенно фреймворков) является поистине вершиной мастерства архитекторов и разработчиков. Сложность здесь кроется в специфике принимаемых решений, ведь акцент серьезно смещается в сторону простоты и удобства использования, расширяемости и надежности. И хотя именно тема разработка библиотек является центральной, книга будет также невероятно полезна и простым разработчикам, ведь знание ключевых идиом языка является совершенно необходимым, когда команда смотрит хотя бы немного дальше своего носа, и заботится не только о написании кода, но и о его последующем сопровождении. Кроме того, книга очень часто выступает таким себе арбитром во многих спорах, касающихся идиом именования, обработке исключений, проектированию собственных классов или использованию других идиом языка C#; а поскольку такие дискуссии происходят с завидным постоянством, то подобный козырь лишним точно не будет.

Дополнительные ссылки: рецензия, amazon.com, ozon.ru (ru)

Mark Seeman, Dependency Injection in .NET, 2011

clip_image028[6]

Лучшая книга об управлении зависимостями и DI-паттернах. Книга очень полезна для корректного применения популярных ныне принципов инверсии управления в своих приложениях. Покрыты ключевые паттерны, такие как Constructor Injection, Method Injection и др, а также рассмотрены негативные стороны использования контейнеров в коде приложения. Однозначно Must Read для каждого .NET-программиста!

Дополнительные ссылки: рецензия, amazon.com, ozon.ru (ru)

 

 

 

 

Функциональное программирование

Современная разработка ПО уже не является чисто объектно-ориентированной, да и никогда ею не была. Любой разработчик со временем начинает понимать пользу других подходов и парадигм. Так, объектная технология идеально подходит для высокоуровневого структурирования программы, но ничем не может помочь, когда дело касается низкоуровневой реализации.

Когда речь заходит о реализации, то на первый план выходит не инкапсуляция и модульность, а декларативность и выразительность, и в этом плане функциональное программирование может быть очень полезным. Современные языки программирования, такие как C# или Java тоже становятся мультипарадигменными, добавляя идиомы функционального программирования на уровне языка.

Не стоит бояться, что ФП идеи нарушают идиллию вашего ОО-мира; эти две парадигмы уже многие годы успешно сосуществуют в языках программирования. Тот же Бертран Мейер (гуру ООП) в своем интервью говорил о пользе совмещения этих двух парадигм: неизменяемость и чистота помогают не только в параллелизме, но и в обеспечении корректности программ. В том же DDD Эванс успешно скрестил ОО и ФП подходы: Value Objects – это классический паттерн функционального программирования, который поддерживается напрямую многими языками программирования.

ФП техники расширяют кругозор и делают из вас более хорошего ОО разработчика.

На рынке есть несколько "гибридных" книг, в которых рассматриваются ФП техники в таких ОО языках как C# или Java. Можно взять одну из таких книг, например, "Real-World Functional Programming" Томаса Петрисека с примерами на C# и F#, или недавно вышедшую книгу Нила Форда "Functional Thinking: Paradigm Over Syntax".

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

Tomas Petricek, Real-World Functional Programming: With Examples in F# and C#, 2010

[clip_image032%255B4%255D.jpg]

Дополнительные ссылки: amazon.com

Neal Ford, Functional Thinking: Paradigm Over Syntax, 2014

Дополнительные ссылки: amazon.com

"Философия" проектирования

Есть несколько хороших книг, в которых не описываются непосредственно подходы к проектированию, но которые могут оказать неоценимое влияние на понимание проблем дизайна и разработки крупных систем. Я говорю о двух книгах Фредерика Брукса: "Мифический человеко-месяц" и "The Design of Design: Essays from a Computer Scientist". И хотя первая книга – это скорее классическая книга для менеджера, но в ней рассмотрено очень много интересных моментов для архитекторов. Вторая книга Брукса также очень хороша: с обилием интересных мыслей в вопросах проектирования в целом, а не только проектирования программного обеспечения.

Фредерик Брукс, Мифический человеко-месяц, или Как создаются программные системы, 1995

Дополнительные ссылки: amazon.com, ozon.ru (ru)

Fred Brooks, The Design of Design: Essays from a Computer Scientist, 2010

Дополнительные ссылки: amazon.com, ozon.ru (ru)

Обратите внимание, что вторая книга Брукса также переведена на русский язык, но перевод весьма неудачен!

Спорные вещи

Есть одна книга, которую многие хотели бы видеть в этом списке. Это книга Роберта Мартина "Принципы, паттерны и методики гибкой разработки на языке C#". Да, это одна из "классических" книг по современным практикам программирования, но на один хороший совет в ней дается 3 сомнительных.

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

Дополнительные ссылки: рецензия, amazon.com, books.ru (ru)

Заключение

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

З.Ы. Понравился пост? Поделись с друзьями! Вам не сложно, а мне приятно;)

23 комментария:

  1. Читал Буча, действительно сильный подход, который меняет мышление.

    ОтветитьУдалить
  2. Как это ни удивительно звучит, книги со словами "объектный" / "ориентированный" в названии про дизайн говорят совсем не то. Они, может, и про "объектный" и даже куда-то "ориентированный" или там "функциональный" - но это всё лишь некоторые рамки, в которых дизайн реализуется.

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

    Хороший дизайн - всего навсего короткое и точное описание того, что код должен делать и чего не должен. Идея, главная мысль. Всё, что есть "…конструирование…", "…ориентированное…" и прочее - это лишь способы aka иснтрументы для вопрощения дизайна. Ну представь себе, к примеру, книжку с заголовком "Фигурное выкладывание плитки в смежных сан-узлах" и назови её книгой по _дизайну_ - смех. И здесь ровно то же самое.

    Про такой дизайн можно узнать у Герба Саттера, например, но нужно немного знать С++. В своих книгах он учит правильной постановке задачи и методичному нахождению решения, а потом - тому, как убедиться в верности решения. Или "Дизайн и эфолюция С++" - то есть книги, в которых читателю даётся некоторая задача, а потом автор разбирает варианты решения задачи, приводит рассуждения о том, почему оказалось сделано так, а не иначе, что ещё можно было бы сделать и поему не сделано так. Мне так же нравится читать на эту тему Дейта.

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

    ОтветитьУдалить
  3. Для меня откровением стали паттерны GRASP. Оказывается все от туда идет. Все остальное следствие их. Поэтому советую в первую очередь прочитать "Применение UML 2.0 и шаблонов проектирования"

    ОтветитьУдалить
    Ответы
    1. Алексей, спасибо за совет. Хотя, как я писал выше, нужно помнить, что то, что подошло одному, не обязательно отлично подойдет другому.

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

      Я, например, пользуюсь принципом единственной ответственности и в жизни, что здорово помогает:)

      Удалить
    2. Очень интересно, Сергей, можешь привести пример каким образом ты пользуешься принципом единственной ответственности в жизни? :)

      Удалить
  4. Сергей, а как же xUnit Test Patterns от Gerard Meszaros? Она вполне достойна, чтобы войти в эти "greatest hits".

    И книгу Марка Симана (Seemann, c двумя "n") можно рекомендовать не только в рамках .NET. Я бы ее поместил на уровень паттернов проектирования, т.к. DI - это и есть набор паттернов, которые не привязаны к конкретной платформе. Помнится Марк даже жалел о том, что вынес .NET в название книги :)

    ОтветитьУдалить
    Ответы
    1. Владимир, да, я думал, над xUnit Test Patterns. Пожалуй добавлю ее в список. И совет о переносе книги Симана в раздел с паттернами тоже валиден:). Спасибо, сделаю.

      Удалить
  5. Посоветуйте пожалуйста, как прочитать с начала и до конца книгу Лармана? Когда я читал HeadFirst, с натугой смог дочитать ее (в конце концов я ее прочитал на процентов 80), при том что книга достаточно увлекательная и не особо скучная. Думаю, "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development" не такая занимательня, т.е более скучная. А если, как советует Сергей, разбавить чтение "Рефакторингом" Фаулера - не потеряю ли я нить книги Лармана? Возможно ли потерять нить вообще, это же не художественная литература все-же, хотя думаю что материал книги основывается на предыдуще изучанном материале. Короче, такая шизоидная проблема. Есть советы?

    ОтветитьУдалить
    Ответы
    1. Если посмотреть на мои посты в Г+, посвященные книге Лармана, то не сложно заметить, что я читал ее более полугода.

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

      Тут нельзя дать другого совета, кроме как читать. Переключаться на что-то другое, когда надоело. Возвращаться снова. Снова переключаться на что-то другое. И потом снова возвращаться.

      Обучение - это сложно, и ни одна из серьезных книг не давалась мне без серьезного труда...

      Удалить
  6. Спасибо Сергей. Наверное это таки-да серьезный труд!

    ОтветитьУдалить
  7. Ссылка на книгу банды четырёх битая, как оказалось.

    ОтветитьУдалить
  8. Вот еще хорошая книга, как мне кажется:
    Харольд Абельсон, Джеральд Джей Сассман "Структура и Интерпретация Компьютерных Программ".
    http://www.ozon.ru/context/detail/id/5322055/
    Еще не читал сам, но очень много позитивных отзывов. Купил.

    ОтветитьУдалить
    Ответы
    1. Алексей, это очень хорошая книга, но она совсем не по ООП. Она скорее по ФП:)

      Удалить
    2. Сергей, а есть хорошие книги по фунциональному программированию на русском языке? Но желательно не учебник по конкретному какому-нибудь языку. А чисто проектирование.
      Хотелось бы почитать про монады. В той книге, что я привел, похоже что нет этого: ни в оглавлении, ни в предметном указателе слово монада не упоминается...

      Удалить
    3. Алексей, так на вскидку, я не помню такого учебника. Можно посмотреть что-то в журнале "Практика функционального программирования", но там будет довольно много продвинутого материала.

      Есть неплохое введение в функциональное программирование в книге Tomas Petricek Real-World Functional Programming. Но там C#/F#, и монад, кажется нет.

      Если интересуют монады, то есть две (как минимум) прекрасные серии статей по этому поводу:

      1. Серия постов Эрика Липперта - http://ericlippert.com/category/monads/
      2. Серия постов на портале F# for fun and profit о Computational Expressions (http://fsharpforfunandprofit.com/series/computation-expressions.html).

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

      Удалить
  9. А есть ли хорошие книги по BDD? И что-то из этого переведено на русский?
    И стоит ли вообще подход BDD применять на практике?

    ОтветитьУдалить
    Ответы
    1. Алексей, мне кажется, BDD пойдет хорошо при правильном понимании, что такое дизайн и юнит-тестирование. Ведь по сути, это такой себе DSL, который может быть и полезен, но явно не является ключевым, ИМХО.

      Поэтому я бы начал с книг по юнит-тестированию, а потом просто почитал пару статей о BDD.

      З.Ы. Книг про BDD я не знаю, да и тема, мне кажется, узковатой для целой книги...

      Удалить
  10. У Бертрана Мейера есть еще одна книга, переведенная на русский - "Почувствуй класс". Написана значительно позже и почти в 2 раза меньше.
    Что скажите по поводу этой книги? Как она по сравнению с тем фундаментальным трудом?

    ОтветитьУдалить
    Ответы
    1. Эта книга - это учебник, который используется (использовался?) в ETH для обучения первокурсников основам программирования. Это значит, что она будет полезной новичкам, но для профессиональных программистов там может быть не такая высокая концентрация полезной информации...

      Удалить
  11. Судя по отзывам на Амазоне, хорошая книга по DDD вышла:
    "Patterns, Principles, and Practices of Domain-Driven Design" (http://www.amazon.com/Patterns-Principles-Practices-Domain-Driven-Design/dp/1118714709/)

    ОтветитьУдалить