Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
«Head First Design Patterns» мне лично не понравилась — много лишних слов, не особо наглядные примеры.
Перестарались они со стилем изложения материала.
При чтении книги меня постоянно клонило в сон :)
При чтении книги меня постоянно клонило в сон :)
А по мне для старта — то, что надо + сразу дают задания попрактиковаться. Хотя вряд ли этого будет достаточно, поэтому, прочитав Head First, купил еще и классику от банды четырех :)
Ну вот, первым же комментом опустили замечательное введение в предмет для новичков. Просто «Head First Design Patterns» написана совсем не для той аудитории для которой предназначена GOF. Нельзя же с одних и тех же позиций оценивать, к примеру, «Занимательную физику» Перельмана и «Справочник по физике для инженеров и студентов вузов». Каждая из них сияет в своей области.
Спасибо, книгу как-то стороной обошел. Обязательно теперь прочитаю.
«Refactoring to Patterns» от Джошуа Кериевски.
Как раз эта книга помогла мне лучше понять некоторые сложные паттерны которые остались недопоняты на уровне Shu :).
Фраза «Шаблонное мышление» в свете Вашей статьи приобретает иной смысл прям таки ).
Большое спасибо за статью! Вы сформулировали и дополнили мои мысли :)
Недавно я маленький комментарий на эту же тему писал: habrahabr.ru/post/166113/#comment_5738499
Недавно я маленький комментарий на эту же тему писал: habrahabr.ru/post/166113/#comment_5738499
Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее
Пытаться вести дискуссию с такими людьми это то же самое что и пытаться объяснить что нехорошо и неправильно чистить семечки на пол в метро, человеку, который это уже делает. Да и вообще страшно представить, что бы произошло с миром программирования, если бы все программисты стермились побыстрее написать код и проповедовали бы это «мне главное решить задачу! Я — решатель задач!» и тому подобное.
Страшный мир уже не за горами, несется к нам на полном ходу! «Решение» задач становится очень даже популярной целью молодых программистов…
В чем проблема? Программиста и нанимают чтоб он как можно быстрее решал задачи.
Ну не совсем так. Зачастую самое быстрое решение — воткнуть костыль. Раз костыль, два костыль, а потом продукт нереально развивать и поддерживать. Приходится переписывать с нуля или же терять клиентов за счет того, что развитие идет слишком медленно. Точечная скорость не всегда важнее стабильности скорости.
Решение задачи это необходимое, а не достаточное условие. Программист, который костылями решает задачу, мало кому нужен, но программист, который ее не решает вообще, не нужен никому.
Правильно понимаю, что не существует нормальной, не сканированной, электронной версии «A Pattern Language» Кристофера Александра?
Если вы про пиратскую копию, то вроде нету.
А если за деньги, то пожалуйста — на сайте www.patternlanguage.com/leveltwo/patterns.htm есть доступ к электронной версии за символические членские взносы в виде 5$/месяц.
Только, вы уверены что вам именно эту книгу надо? там шаблоны городской застройки, архитектуры, дизайна — тоже очень интересно, но некоторые разочарованно говорят «у-у-у, обманули...»
А если за деньги, то пожалуйста — на сайте www.patternlanguage.com/leveltwo/patterns.htm есть доступ к электронной версии за символические членские взносы в виде 5$/месяц.
Только, вы уверены что вам именно эту книгу надо? там шаблоны городской застройки, архитектуры, дизайна — тоже очень интересно, но некоторые разочарованно говорят «у-у-у, обманули...»
С людьми, которые сначала не понимают прелесть того или иного шаблона проблем нет. Проблемы начинаются с товарищами, вчера прочитавших про три-четыре новых шаблона и втыкающих их повсеместно и беспорядочно.
В частности, для C++ крайне опасно всё фабричное, ибо в большинстве случаев полезет в Heap за памятью, что не есть дёшево.
В частности, для C++ крайне опасно всё фабричное, ибо в большинстве случаев полезет в Heap за памятью, что не есть дёшево.
Это и есть та цепочка, которую я называл «от шаблона к решению». Прочитал о шаблонах проектирования -> впечатлился -> надо применять знания на практике -> айда подводить все проблемы под шаблоны -> на выходе шаблонно-костыльный код… Неприятная дорожка!
А как вы поступали, когда только прочитали про шаблоны?
Согласен с автором. Паттерны проектирования нужны. Без них ни как. Более того, считаю что в настоящее время в большинстве случаев архитектурная проблема является главной в разработке ПО (в сравнении например с оптимизацией или алгоритмической проблемой), т.к. пользователь скорее выберет тормозящее и ограниченное, но корректно и стабильно работающее ПО. Невозможно построить крупную систему без хорошей архитектуры, иначе после определенного критического объема она просто развалится.
P.S. Все выше сказанное лишь субъективные наблюдения. Являясь сисадмином я не занимаюсь разработкой ПО профессионально. Однако в свободное время создаю ПО для души, уделяя бОльшую часть времени архитектурным вопросам.
P.S. Все выше сказанное лишь субъективные наблюдения. Являясь сисадмином я не занимаюсь разработкой ПО профессионально. Однако в свободное время создаю ПО для души, уделяя бОльшую часть времени архитектурным вопросам.
В области бухгалтерского софта безусловно, но если говорить про что то серьёзное: системы проектирования, симуляции, компьютерной графики, то я бы так легко «алгоритмическую» проблему не списывал (а так-же математическую или физическую) В этих областях без решения этих задач никакая архитектура не поможет.
Плохо когда разработка превращается в pattern-driven программирование — есть у меня знакомые, которые и HelloWorld раздуют в нечто невообразимое, зато все по GOFу
Вы на 100% правы. Именно поэтому стоит давать волю шаблонотворчеству только на уровне Ha. А до этого команда с помощью ревью кода и совместного обсуждения дизайна контролирует страсти по шаблонам у особо ярых их сторонников.
Уметь применить тридцать два паттерна в HelloWorld надо, даже если это не пригодится в реальной практике.
Мой любимый паттерн — это Слабое связывание [ Low Coupling ].
Его принцип прослеживается во многих паттернах.
Мне, например, легче применять один основной принцип, чем пытаться оперировать целой кучей шаблонов.
Его принцип прослеживается во многих паттернах.
Мне, например, легче применять один основной принцип, чем пытаться оперировать целой кучей шаблонов.
Можно сказать, что все паттерны состоят из 3 компонент — полиморфизм, инкапсуляция, наследование
Даже вроде бы статья про это была на Хабре
Даже вроде бы статья про это была на Хабре
Я бы сказал — не только.
Есть еще cohesion и coupling.
Есть принцип единой ответственности.
Есть процедурный, объектно-ориентированный и функциональный подходы.
И есть еще много чего, и все это, примененное в гармонии, вызывает в нас чувство прекрасного.
Паттерны — это не только голые скелеты указанных трех компонент. Они описывают форму, но не содержание.
Кстати, именно поэтому есть даже пара паттернов, имеющих совершенно одинаковую структуру. Предлагаю Вам найти их самостоятельно, чтобы понять, что Вы упуская, размышляя предложенным Вами способом.
Не все так просто,
Как нам кажется порою,
Не все так сложно,
Как логический узор,
Все гармонично,
Только кинь иначе взор — И глубина тотчас
Открыта пред тобою,
Лишь улови… (с)
Есть еще cohesion и coupling.
Есть принцип единой ответственности.
Есть процедурный, объектно-ориентированный и функциональный подходы.
И есть еще много чего, и все это, примененное в гармонии, вызывает в нас чувство прекрасного.
Паттерны — это не только голые скелеты указанных трех компонент. Они описывают форму, но не содержание.
Кстати, именно поэтому есть даже пара паттернов, имеющих совершенно одинаковую структуру. Предлагаю Вам найти их самостоятельно, чтобы понять, что Вы упуская, размышляя предложенным Вами способом.
Не все так просто,
Как нам кажется порою,
Не все так сложно,
Как логический узор,
Все гармонично,
Только кинь иначе взор — И глубина тотчас
Открыта пред тобою,
Лишь улови… (с)
Отличная мотивирующая статью. Короткая конечно, но это можно и к плюсам отнести.
Читая, сразу вспомнил книгу «PHP. Объекты, шаблоны и методики программирования» — как мне кажется, Мэтт Зандстра максимально полно передал преимущества использования шаблонов, да и вообще правильные подходы объектного проектирования. Очень советую прочитать, и не только PHP-программистам!
Читая, сразу вспомнил книгу «PHP. Объекты, шаблоны и методики программирования» — как мне кажется, Мэтт Зандстра максимально полно передал преимущества использования шаблонов, да и вообще правильные подходы объектного проектирования. Очень советую прочитать, и не только PHP-программистам!
Через четыре года после GoF была опубликована фундаментальная работа "Шаблоны проектирования в динамических языках", в которой показывалось, что в функциональных языках программирования основные «классические» шаблоны проектирования вырождаются в нечто тривиальное — или вообще элиминируются или превращаются в макрос или функцию. В 2002 году Пол Грэхэм написал, что «шаблоны проектирования» — это частный случай промежуточного результата ручной компиляции с функционального языка типа LISP. Ну, поэтому, я эти «шаблоны проектирования» не замечал довольно долго (хотя и, как потом выяснилось, применял вовсю), так как мыслил в категориях функциональных языков «измысливал» сразу оригинал вместо искажённого образа.
Интересно, что почти любой инструмент разработки — может стать предметом холивара.
Давайте сначала — что такое шаблоны проектирования? Вообщето частный случай решения некой задачи. Зная который, Вы можете легче решать задачи в будущем, если они совпадают с той самой «некой». Думаете «шаблоны» — это всего лишь придурь разрабов? Нет, любой инженер знает типовые схемы «чего-то там». Даже у шахматистов и футболистов есть типовые шаблоны поведения.
так что я считаю — крайне вредны обе крайности. И полное незнание паттернов (вы к ним всё равно прийдёте, просто набьете кучу шишек по дороге), и слепое подчинение паттернам — когда архитектурные изыски создаются ради голых архитетктурных изысков. Да, полученное решение может быть далеко не самым худшим, но, возможно, и лучшим оно не будет. Ведь постоянно появляются новые паттерны, а значит «самый лучший код» — ещё не написан.
Давайте сначала — что такое шаблоны проектирования? Вообщето частный случай решения некой задачи. Зная который, Вы можете легче решать задачи в будущем, если они совпадают с той самой «некой». Думаете «шаблоны» — это всего лишь придурь разрабов? Нет, любой инженер знает типовые схемы «чего-то там». Даже у шахматистов и футболистов есть типовые шаблоны поведения.
так что я считаю — крайне вредны обе крайности. И полное незнание паттернов (вы к ним всё равно прийдёте, просто набьете кучу шишек по дороге), и слепое подчинение паттернам — когда архитектурные изыски создаются ради голых архитетктурных изысков. Да, полученное решение может быть далеко не самым худшим, но, возможно, и лучшим оно не будет. Ведь постоянно появляются новые паттерны, а значит «самый лучший код» — ещё не написан.
Такое впечатление, что большинство комментаторов не читали статьи. Прочтите хотя бы выделенные жирным основные моменты.
Паттерны нужно изучать не для того, чтобы их применять. Ведь большинство из них очень просты и могут быть «изобретены» на ходу.
Основные плюсы знания паттернов — коммуникация с другими разработчиками и ускоренное изучение чужого кода.
Паттерны нужно изучать не для того, чтобы их применять. Ведь большинство из них очень просты и могут быть «изобретены» на ходу.
Основные плюсы знания паттернов — коммуникация с другими разработчиками и ускоренное изучение чужого кода.
Основные плюсы знания паттернов, да вообще любого знания — больше вариантов решения.
Методы, принципы, схемы, паттерны, языки, фреймворки — это всего лишь инструменты.
Я когда делал ремонт, пользовался перфоратором, шуруповертом, молотком, пилой и т.д.
Без шуруповерта тоже можно было, в принципе, но с ним проще и быстрее.
Возможно, можно было сделать ремонт одним перфоратором — и сверлить, и заворачивать шурупы, и забивать гвозди — но у меня было несколько инструментов, и я ими пользовался в тех случаях, когда это было уместно.
При увеличении поля знаний возрастает вероятность придумать что-то новое, проще решить какую-то задачу, т.к. количество комбинаций растет. С опытом приходит понимание, что и как лучше использовать.
И да, я согласен, если другой человек знает то же, что и вы, разговаривать проще. Можно не говорить «устройство, которое вращает сверло и одновременно долбит им», а сказать «перфоратор».
Методы, принципы, схемы, паттерны, языки, фреймворки — это всего лишь инструменты.
Я когда делал ремонт, пользовался перфоратором, шуруповертом, молотком, пилой и т.д.
Без шуруповерта тоже можно было, в принципе, но с ним проще и быстрее.
Возможно, можно было сделать ремонт одним перфоратором — и сверлить, и заворачивать шурупы, и забивать гвозди — но у меня было несколько инструментов, и я ими пользовался в тех случаях, когда это было уместно.
При увеличении поля знаний возрастает вероятность придумать что-то новое, проще решить какую-то задачу, т.к. количество комбинаций растет. С опытом приходит понимание, что и как лучше использовать.
И да, я согласен, если другой человек знает то же, что и вы, разговаривать проще. Можно не говорить «устройство, которое вращает сверло и одновременно долбит им», а сказать «перфоратор».
«Многие шаблоны проектирования в объектно-ориентированном проектировании можно рассматривать как идиоматическое воспроизведение элементов функциональных языков.» Вики (с). Помню как первый раз увидел шаблоны — думаю, вот это чудо расчудесное. Конечно шаблоны нужны, в шарпе, сях, яве и других похожих языках. Хорошо, что мир придумал и более удачные решения (питон ванлав).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Для чего нужны шаблоны проектирования