Comments 15
Читал обе книжки, могу добавить, что первая книга подходит именно для изучения паттернов, где описаны проблемы при разработке, и постепенно рефакторингом приходят в конечном итоге к решению проблемы с помощь определённого паттерна.
А вторая книга - подходит в качестве справочника.
я не утверждаю, что паттерны проектирования безусловно необходимы, и что если человек не прочитал паттерны Банды Четырех, то он не может называться разработчиком
Паттерны проектирования - не серебряная пуля, но их знание по-моему необходимо для разработчиков, которые работают в команде. Т.к. зная паттерны - вы владеете терминами, под которыми понимаете одно и тоже решение, и это очень упрощает при коммуникации.
Вам потом проще кому-то сказать "возьми библиотеку http-клиента, и напиши к ней декоратор логов" или "для использования такой библиотеки-логирования в нашем проекте, необходимо написать к нему адаптер".
Кто-нибудь проводил исследования того, что было до и что стало после применения паттернов?
Мне кажется эти книги вообще надо изъять из продажи и запретить их издание в будущем. Так как они очень быстро и слишком сильно разъедают мозги программистам, Первым делом съедают ту часть которая отвечает за здравый смысл и критическое мышление. Программисты начинают воспринимать эти паттерны как догму, без которой нельзя написать ни строчки кода. Частично, наверное, это ещё и усиливается процессами найма, на каждом собеседовании спрашивают про эти паттерны.
В результате для решения совершенно простой задачи используются все эти паттерны, и получается ужасный код, полностью напичканый фабриками и строителями. Совершенно не поддерживаемый код. FizzBuzz Enterprise edition в чистом виде.
Да паттерны нужны но в очень редких случаях, и скорее они про дизайн в целом приложения. И приложение должно быть достаточно большое.
Но когда простейшее приложение, которое читает CSV-файл с диска и просто загружает его в табличку БД полностью напичкано фабриками, билдерами и вот этим всем - зачем.
"А на каждую кнопку повесьте system.sleep(5000), чтобы заказчик видел, что это не наколенная поделка, а высоконагруженный бизнес инструмент решающий сложные задачи"
Мне кажется эти книги вообще надо изъять из продажи и запретить их издание в будущем.
Зачем такие радикальные методы? Шаблонами пользоваться гораздо легче, нежели новыми велосипедами без сидушки. Просто нужно в головы несведующих вбивать на каждой странице, что это не требования, а обобщения, инструмент, если угодно, но никак не руководство к действию. В том, что везде нужна мера я с Вами полностью согласен, но такие книги нужны. Вопрос в том, что должно пройти время, чтобы понять где это действительно можно и НУЖНО применять.
на каждом собеседовании спрашивают про эти паттерны.
Джуна вряд ли о таком спросят, а вот мидл, а тем более сеньор просто показывает таким образом, что он знает, что это такое и как этим инструментом пользоваться.
Хочу всё-таки немного поспорить с такой позицией.
Если на выходе получается "FizzBuzz Enterprise" -- это означает, что у кандидата/разработчика нет понимание того, что и зачем он делает, какую проблему решает и т.д. и т.п
Само по себе знание паттернов тут не причём, имхо. Мне не кажется правильным обвинять микроскоп в том, что кто-то забивает им гвозди
И конечно же нужно процитировать классику:
«In the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.».
я не утверждаю, что паттерны проектирования безусловно необходимы, и что если человек не прочитал паттерны Банды Четырех, то он не может называться разработчиком
От вас, кажется, ускользнуло главное. Паттерны не то что "нужны или не нужны". Они просто есть. Есть ряд стандартных задач - есть ряд стандартных решений. Даже если кого-то трясет в негодовании от одного слова "паттерны", то это ничего не меняет. В коде таких людей тоже гарантированно есть повторяющиеся приемы. Просто умные дяди GOF эти приемы обобщили.
Ну и по теме. Утверждать после одного лишь чтения, что вы что-то "качественно изучили" это несерьезно. Паттерны - сугубо практическая тема. Книга тут лишь отправная точка и толчок к размышлению.
Мне одному кажется, что когда человек говорит "Банда Четырех" то, "Банда Четырех" сё, он как будто привстает на маленькую скамеечку.
Я спустя 10 лет работы начал читать GoF. Правда, она читается очень сложно.
Но книга хорошая. Наконец разобрался с паттернов Визитор.
Вот ещё одна неплохая книга по теме: Александр Швец - Погружение в паттерны проектирования. Подача материала где-то посередине между упомянутыми в посте, без натужного юмора, но и не чересчур сухая. В тексте примеры на псевдокоде, а в сопутствующих репозитариях ещё на десятке популярных языков.
Лучше сначала изучить функциональное программирование. Потом SOLID. Тогда эти паттерны станут очевидными.
Head First - можно прочитать для ознакомления. Вторая уже устарела, как и объектно-ориентированное проектирование.
Знать паттерны и понимать как они реализуются в реальном мире - это два разных знания.
Как и в любом мастерстве, можно узнать миллион умных слов и миллион умных идей. Но если ты не одну из них не реализовал на конкретном примере, то все они остаются лишь надуманными представлениями о реальности.
Решайте задачи и ищите пути оптимизации в паттернах. Тогда и паттерны выучите и поймёте их быстрей, т.к. они будут прикреплены к реальному опыту.
Способ качественно изучить паттерны проектирования