В догонку — паттерны не должны быть самоцелью, это не инструмент и не средство, это база знаний, каталог материалов по аналогии со строительством — любой инженер-строитель скажет, что вот в таком случае лучше использовать цемент М500, а в таком М300 и т.п. и т.д.
... По ушам лупит "Cardigans — My Favourite Game" ...
Re[3]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, bugmaker, Вы писали:
G>Наши американские друзься изобрели несколько паттернов, из которых я запомнил два: G>- multiple singleton (sic!) G>- shared aggregation ( ) G>Рак мозга короче.
Занятно. Узнать, что это такое, можно?
G>Паттерны это не инструмент проектирования. Вранье чистой воды. Ну не думает грамотный проектировщик над тем, какой бы ему паттерн привернуть, чтобы все заработало. Вместо этого он анализирует функционал объектов и отношения между ними, не до паттернов ему. Так скажем, он работает на более детальном уровне. А вот когда дизайн закончен, вы найдете в нем много паттернов, в том числе и известных. Парадокс, однако .
Паттерны — это оружие проектировщика. Хороший проектировщик, действительно, не просто знает о них, он ими думает. Можно их назвать не по буржуйски — паттернами, а просто приемы работы. И этими приемами и умением их применять, как раз, и ценен дизайнер или архитектор. И именно этим они отличаются от других разработчиков. Ведь именно кардиолог лечит сердце, хотя и остальные врачи оканчивали мед. институт. Специализация, великая вещь. И у проектировщиков есть своя специализация.
В основном, это, действительно, постигается только опытом, и именно опыт определяющая вещь. К сожалению, многие у нас включают свою гениальность не обладая знаниями и опытом. И результат получается соответствующий. Может вы с этим не встречались, а я встречался. Переписывались значительные куски кода, из-за того, что приделать новую функциональность было невозможно. Или для какой-то функциональности, приходилось пробегать по 20 мб сырцам. Или процедура на 10000 строк. Если бы человек хотя бы знал, что такое рекурсивная декомпозиция. Ошибки дизайна и архитектуры, очень тяжелые ошибки.
С уважением, Gleb.
Re[3]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, Gaperton, Вы писали:
G>>Паттерны это не инструмент проектирования. Вранье чистой воды. Ну не думает грамотный проектировщик над тем, какой бы ему паттерн привернуть, чтобы все заработало. Вместо этого он анализирует функционал объектов и отношения между ними, не до паттернов ему. Так скажем, он работает на более детальном уровне. А вот когда дизайн закончен, вы найдете в нем много паттернов, в том числе и известных. Парадокс, однако .
K>Не могу судить однозначно — я не грамотный проектировщик. Но разве паттерны не описывают некоторые часто используемые отношения между объектами?
Да и нет.
Во первых, группа объектов в реальном дизайне часто реализует сразу несколько паттернов, причем так, что вы не сможете выделить границы примененных паттернов — они пойдут внахлест. Придумать такое отталкиваясь от паттернов (как пытаются делать многие, по моим наблюдениям) довольно тяжело, здесь надо думать скорее о функциях объектов и их отношениях.
Во вторых, паттерны не имеют никакого отношения к предметной области, и это главное. Разработка правильного дизайна есть в первую очередь учет требований к системе, и главный критерий качества модели — ее соответствие текущим (и предполагаемым будующим) требованиям к системе. Не существует универсального критерия оценки качества дизайна, оторванного от прикладной задачи, это, я думаю всем очевидно. Если в дизайне будут дыры, они станут в первую очередь видны при попытке наложить на систему тот или иной use case, возможно, системного уровня. А соответствие системы известным паттернам — не критерий, или по крайней мере не первичный критерий.
Вывод? Паттерны это просто имена для часто всречающихся конфигураций функционала в ОО системе, и все. Объяснить коллеге ваш подход к дизайну удобно используя терминологию общеупотребимых паттернов.
K>Естественно проектировщик анализирует функционал и отношения и прочее, но когда он знает о проверенном типовом решении (паттерн?) — обязательно его применит.
Пардон? Синглтон — "проверенное типовое решение"? Есть варианты "непроверенных" способов сделать что-то подобное? Пул разделяемых объектов — это проверенное решение? Да вы просто не сможете без него обойтись, если он понадобится. Когда речь заходит о паттернах как о "проверенных решениях", я просто не понимаю, о чем речь. Реализован-то паттерн может быть как угодно, так?
K>Не будет же проектировщик на каждом проекте изобретать все отношения заново. А уж как назвать это типовое решение, паттерн или непаттерн, — дело десятое.
Рассмотрите известные книги о процессе ОО анализа и дизайна, например OMT (Rumbaugh) или книгу про CRC карты. Найдете там что-нибудь про паттерны? Вряд-ли. Вообще, приведите ссылку хотя бы на одно законченное описание целостного подхода к ОО дизайну с применением паттернов. Мне было-бы интересно про такое почитать.
G>>Однозначная польза от паттернов только одна — введение общей терминологии. Что успешно сводится на дерьмо, так как все сремяться придумать побольше разных "паттернов", и назвать их как нибудь по своему. Вот у нас в команде — как? Наши американские друзься изобрели несколько паттернов, из которых я запомнил два: G>>- multiple singleton (sic!) G>>- shared aggregation ( ) G>>Рак мозга короче.
K>"ибо сказано не плодите сущностей сверх необходимости" K>Разве рак мозга в паттернах?
В людях, которые верят в магию паттернов
K>Каталог паттернов очень полезная штука — всего сам не придумаешь, будь ты трижды гениален. K>А расширит этот каталог только время — я, например, из каталога Гаммы и Co (уж на что брутальная вещь) использую всего несколько паттернов, на остальные потребности пока не вижу.
[ИМХО] чтение таких каталогов не лучшая трата времени. Книга гаммы и остальных — это другое, они описывают разработку законченной системы (!) [/ИМХО]
Re[4]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, Gaperton, Вы писали:
G>....отталкиваясь от паттернов (как пытаются делать многие, по моим наблюдениям) ... G>... А соответствие системы известным паттернам — не критерий, или по крайней мере не первичный критерий. G>... хотя бы на одно законченное описание целостного подхода к ОО дизайну с применением паттернов... G>В людях, которые верят в магию паттернов
Со всем согласен.
Я старался сделать акцент на том, что паттерны не ключевая вещь, не панацея и не надо ставить их во главу угла. Но видимо не получилось
G>Пардон? Синглтон — "проверенное типовое решение"? Есть варианты "непроверенных" способов сделать что-то подобное? Пул разделяемых объектов — это проверенное решение? Да вы просто не сможете без него обойтись, если он понадобится. Когда речь заходит о паттернах как о "проверенных решениях", я просто не понимаю, о чем речь. Реализован-то паттерн может быть как угодно, так?
Под словом "проверенные" понималось ранее придуманные и использованные, т.е. это к вопросу о придумывании новых паттернов.
G>[ИМХО] чтение таких каталогов не лучшая трата времени. Книга гаммы и остальных — это другое, они описывают разработку законченной системы (!) [/ИМХО]
Это и есть каталог паттернов и примеры их использования. Разве не так?
G>Вывод? Паттерны это просто имена для часто всречающихся конфигураций функционала в ОО системе, и все. Объяснить коллеге ваш подход к дизайну удобно используя терминологию общеупотребимых паттернов.
Когда я читал книгу Гаммы, узнал много новых "часто всречающихся конфигураций функционала в ОО системе". Разве это не одна из функций паттернов?
... По ушам лупит "начальство" ...
Re[2]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, bugmaker, Вы писали:
B>>как относитесь к подобному взгляду? GZ>Отрицательно. GZ>1. Разработчику, который только что усвоил, что такое абстракция и инкапсуляция, трудно объяснить как все это применять.
Разработчику, который только что усвоил, что такое абстракция и инкапсуляция, не нужно объяснить как все это применять. Если он усвоил, то он знает как использовать полученные знания.
GZ>... если берешься за новую область, сначало прочитай теорию, и только после этого изучай практику. Только тогда дается ясное понимание того, как это работает, что ты делаешь, и оссобенно, как ты это будешь делать.
-1
Чистая теория так же вредна, как и практика без теории. Я вообше не стал бы разделять эти понятия. Для того, чтобы чему-то научиться, выработать какие-то навыки необходимо это делать. Приведу аллегорию: Сколько бы книг о лошадях ты не прочитал, ты не научишься ездить на лошади, пока на нее не сядешь.
GZ>2. Общая терминология. Когда ты говоришь, что ты здесь построишь фабрику классов, становится понятно что такое фабрика классов, для чего она здесь, и что другие от этого будут иметь.
+1
Согласен
GZ>3. Удобно посылать. Когда надо доказать свою точку зрения, можно всегда послать на ссылку, с гордым видом высказывая: "Это не я так утверждаю, а наука".
-1
То, что так утверждает наука, лично для меня не является убедительным аргументом при доказательстве. Это скорее повод к размышлению.
Аристотель в свое время утверждал, что у паука 6 ног и тяжелые предметы падают быстрее, чем легкие.
Истину, чтобы она не стала догмой, всегда нужно подвергать сомнению и перепроверять, независимо от того, насколько авторитетного источника она исходит: Аристотеля, Александреску или Фаулера.
GZ>Не менее полезны (а может более) антипаттерны.
+1
--
Дмитро
Re[3]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, dshe, Вы писали:
GZ>>1. Разработчику, который только что усвоил, что такое абстракция и инкапсуляция, трудно объяснить как все это применять.
D>Разработчику, который только что усвоил, что такое абстракция и инкапсуляция, не нужно объяснить как все это применять. Если он усвоил, то он знает как использовать полученные знания.
Не знает!!! И это касается не только касается данной области. Можно описать любоет решение как некоторую точку в многомерном пространстве проблем. И неопытный разработчик (а иногда и опытный) не всегда видит, все измерения и их шкалу и во что, это решение выльется. Эти вещи познаются только предыдущим опытом или экспериментом. И учатся на ошибках. Если разработчик будет тупо плодить интерфейсы, и инкапсулировать кучу различных ненужных вещей, то он доведет всю идею до маразма, и не сможет построить эффективное приложение. Такое приложение невозможно будет сопровождать.
Вообще, паттерны проектирования — это всего лишь маленькая часть того, что должен знать разработчик (особенно если он работает самостоятельно). И не стоит смешивать умение применения паттернов и декомпозицию сущностей. Они очень похожи, но это не одно и то же.
GZ>>... если берешься за новую область, сначало прочитай теорию, и только после этого изучай практику. Только тогда дается ясное понимание того, как это работает, что ты делаешь, и оссобенно, как ты это будешь делать.
D>-1 D>Чистая теория так же вредна, как и практика без теории. Я вообше не стал бы разделять эти понятия. Для того, чтобы чему-то научиться, выработать какие-то навыки необходимо это делать. Приведу аллегорию: Сколько бы книг о лошадях ты не прочитал, ты не научишься ездить на лошади, пока на нее не сядешь.
+1. И чем это отличается от того что я до этого написал?
GZ>>3. Удобно посылать. Когда надо доказать свою точку зрения, можно всегда послать на ссылку, с гордым видом высказывая: "Это не я так утверждаю, а наука".
D>-1 D>То, что так утверждает наука, лично для меня не является убедительным аргументом при доказательстве. Это скорее повод к размышлению. D>Аристотель в свое время утверждал, что у паука 6 ног и тяжелые предметы падают быстрее, чем легкие. D>Истину, чтобы она не стала догмой, всегда нужно подвергать сомнению и перепроверять, независимо от того, насколько авторитетного источника она исходит: Аристотеля, Александреску или Фаулера.
Интересная точка зрения.
1. Если бы каждый физик, или тот же Циолковский, начал бы доказывать теорию Ньютона, то мы бы никогда не построили ракету. Если бы Энштейн не создал теорию Относительности, мы бы никогда не узнали, что теория Ньютона не верна. Принято считать, что теория Ньютона всегда верна при определенных условиях. Точно так же и в программировании, нужно знать и пользоваться верной теорией, и не поддвергать ее сомнению. Иначе наделаешь кучу ошибок, или пройдешь уже по пройденному пути. Но знать ее границы. А догм пока нет, как и серебрянной пули.
2. В последнее время очень трудно отделить маркетинг от теории. Поэтому стоит выбрать источники, которым ты доверяешь на 100%.
3. Если мне подойдет человек, и скажет, что принял решение по той или иной причине, укажит источники (или эти источники общеизвестны), то такой человек мне нравится больше, чем человек который скажет: "А так круче". Решение второго придется проверять и перепроверять, то есть выполнять его функции.
4. Стоит выбрать, чем ты в данный момент занимаешься, производством программных продуктов или наукой.
С уважением, Gleb
Re: как относитесь к подобному взгляду на паттерны?
Здравствуйте, bugmaker, Вы писали:
B>как относитесь к подобному взгляду?
Любая точка зрения имеет право на существование. Вокруг паттернов уже наврчено столько всего разного, столько уже состоялось плясок с бубнами, а так же столько раз их уже пытались выдать за очередную панацею — окончательное и бесповоротное решение всех проблем, что действительно иногда возникает впечатление, что паттерны вообще — большой мыльный пузырь.
Но по сути я с этой точкой зрения не согласен, так как на мой взгляд — это следствие ошибочного отношения к самим паттернам и их возможностям. Как мне кажется — паттерны, в том виде, каком их описывают в литературе, в реальных проектах применяются крайне редко (если вообще применяются), за редчайшими исключениями — вроде файбрики классов. Но они для этого и не предназначены! По-моему большинство паттернов представляют собой вовсе не готовые решения (а-ля кубик), а приёмы — которыми можно пользоваться, для создания подобных кубиков для реального проекта. На мой взгляд различие между паттернами проектирования и реальными проектными решениями — похоже на различие между простеньким интерфейсом и сложной реализацией — поддерживающей несколько таких интерфейсов. Но вот что действительно полезно — так это не столько сами паттерны — а процесс "патернирования" кода, т.е. систематического анализа кода с применением и рассмотрением таких понятий как связность, связанность, зацепление, отсветственность, множественность. Так как подобный процесс позволяет:
— выделить кубики, реально осмысленные в рамках проекта
— сформировать язык разработчиков проекта и документации, на основе выденных "кубиков"
— яснее представлять возможности и гибкость изменения проекта, в огромной степени проистекающую из кубиков, лежащих в основе архитектуры (дизайна проекта) и самой архитекутры (которая сама составлена из кубиков и является одним из кубиков)
— повысить эффективность общения, так как можно говорить о кубиках — имеющих чёткую цель и смысл, но в тоже время более высокоуровневых, чем отдельные классы.
— совершенствовать и развивать мышление проектировщиков и разработчиков, повышая уровень абсракции.
Впрочем это сугубо моя собственная точка зрения...
Re[5]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, kavlad, Вы писали:
G>>[ИМХО] чтение таких каталогов не лучшая трата времени. Книга гаммы и остальных — это другое, они описывают разработку законченной системы (!) [/ИМХО] K>Это и есть каталог паттернов и примеры их использования. Разве не так?
Зависит от точки зрения. На мой взгляд (имхо), от простого каталога паттернов эту книгу отличает то, что она довольно связно рассказывает о дизайне текстового процессора. Заостряя моменты на удачных примерах решения дизайнерских проблем. Т. е. это не каталог паттернов с иллюстрацией на примере текстового процессора, а описание дизайна текстового процессора с иллюстрациями в виде паттернов . Разница существенная. Паттерны здесь не главное — главное, что вам показывают проблемы в дизайне и их решения (оформленные в виде паттернов; авторы книги, впрочем, выставляют все иначе). При этом, вам не рассказывают, как авторы пришли к этим решениям (!). Читать ее, меж тем, все равно интересно; с моей точки зрения, главная заслуга авторов — им удалось показать красоту ОО дизайна, что он может быть одновременно легок, прост, функционален и красив. Очень жизнеутверждающая и мотивирующая к качественной работе книга.
G>>Вывод? Паттерны это просто имена для часто всречающихся конфигураций функционала в ОО системе, и все. Объяснить коллеге ваш подход к дизайну удобно используя терминологию общеупотребимых паттернов. K>Когда я читал книгу Гаммы, узнал много новых "часто всречающихся конфигураций функционала в ОО системе". Разве это не одна из функций паттернов?
Возможно. Как вы считаете, зная описание этих паттернов у вас получится их воспроизводить в своем дизайне? А может, вы уже давно это делаете, но просто не смотрели на собственный дизайн под таким углом, и находитесь под впечатлением открывшейся картины? У меня эйфория от "открывшихся возможностей" после прочтения Гаммы (5 лет назад) прошла за 2 дня, когда я понял, что ничего, собственно, нового в процесс моего дизайна паттерны не привносят, я рассуждаю при дизайне совсем другими категориями (сценарии-функции-отношения-потоки данных), а паттерны у нея внутре все равно воспроизводятся с завидной регулярностью, причем даже те, названий которых я не знаю. Да и хрен с ними, в конце концов, пускай .
Как я уже говорил, [ИМХО]единственной полезной и реально работающей функцией паттерна я считаю иллюстративную функцию — применение терминологии и методологии паттернов позволяет упорядочить и структурировать изложение дизайна существующей системы, особенно если она сложна. Но не разработку.[/ИМХО] Бо все остальное заявленное про паттерны сильно конфликтует с моим личным, само собой, субъективным, опытом.
Re[6]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, Gaperton, Вы писали:
G>Зависит от точки зрения. На мой взгляд (имхо), от простого каталога паттернов эту книгу отличает то, что она довольно связно рассказывает о дизайне текстового процессора. Заостряя моменты на удачных примерах решения дизайнерских проблем. Т. е. это не каталог паттернов с иллюстрацией на примере текстового процессора, а описание дизайна текстового процессора с иллюстрациями в виде паттернов . Разница существенная. Паттерны здесь не главное — главное, что вам показывают проблемы в дизайне и их решения (оформленные в виде паттернов; авторы книги, впрочем, выставляют все иначе). При этом, вам не рассказывают, как авторы пришли к этим решениям (!). Читать ее, меж тем, все равно интересно; с моей точки зрения, главная заслуга авторов — им удалось показать красоту ОО дизайна, что он может быть одновременно легок, прост, функционален и красив. Очень жизнеутверждающая и мотивирующая к качественной работе книга.
Может быть черезчур категорично, но с основной мыслю согласен. Дествительно пожалуй самое интересное, не само по себе прменение паттерна, а причины, по которым был выбран тот или иной паттерн. Особенно — на ранней стадии развития системы. Тут очень многое зависит от интуиции проектировщика — от его умения предвидеть, в какую сторону будут изменяться требования к системе и как это будет отражатся на коде. Вот способ потому способ, как выбирается подходящий паттерн (рассматривая паттерн в широком смысле — как некое выделенное из кода и изолированное от лишних деталей решение, не обязательно известное или встречающееся у других) — действительно пожалуй важнее и интереснее самого паттерна. Так как именно от его эффективности будет зависеть частота и интенсивность изменения кода.
K>>Когда я читал книгу Гаммы, узнал много новых "часто всречающихся конфигураций функционала в ОО системе". Разве это не одна из функций паттернов? G>Возможно. Как вы считаете, зная описание этих паттернов у вас получится их воспроизводить в своем дизайне? А может, вы уже давно это делаете, но просто не смотрели на собственный дизайн под таким углом, и находитесь под впечатлением открывшейся картины? У меня эйфория от "открывшихся возможностей" после прочтения Гаммы (5 лет назад) прошла за 2 дня, когда я понял, что ничего, собственно, нового в процесс моего дизайна паттерны не привносят, я рассуждаю при дизайне совсем другими категориями (сценарии-функции-отношения-потоки данных), а паттерны у нея внутре все равно воспроизводятся с завидной регулярностью, причем даже те, названий которых я не знаю. Да и хрен с ними, в конце концов, пускай .
Согласен. Почему то такие вещи, как callback вызов, интерфейс, полиморфизм, выделение в модуль — хотя очевидно являются типовыми решениями и используются даже чаще чем самые распространённые паттерны (вроде файбрики или файбричного метода), но по какой то загадочной причине к паттернам не относятся. С моей точки зрения всё ООП — это не что иное, как наука о паттернах (т.е. о неких приёмах, дающих чёткий, прогнозируемый и воспроизводимый результат), т.к. на мой взгляд программирование таки состоит почти сплошь из паттернов разных логических уровней (например, класс или функция по моему очевидные паттерны, но распространены так широко, что о них в таком качестве никто и не думает — они воспринимаются столь же естественно, как воздух).
G>Как я уже говорил, [ИМХО]единственной полезной и реально работающей функцией паттерна я считаю иллюстративную функцию — применение терминологии и методологии паттернов позволяет упорядочить и структурировать изложение дизайна существующей системы, особенно если она сложна. Но не разработку.[/ИМХО] Бо все остальное заявленное про паттерны сильно конфликтует с моим личным, само собой, субъективным, опытом.
Опять-таки — слишком категорично. Это одна из их функций. Основное — чему учат паттерну — умению "паттернировать" — т.е. выделять из кода некие решения — которые или можно затем тиражировать или же как минимум просто рассматривать их свойства и проектировать с их помощью систему — абстрагировавшись от лишних деталей, не имеющих отношения к работе выделенного паттерна. Действительно при проектировании мы обычно используем категории — отличные от перечисленных в книге Гаммы 12 паттернов. Но если разобраться — мы используем множество собственных паттернов (например те же потоки данных ты ведь наверняка рассматриваешь и обдумываешь не просто так — изолированно ото всего — а скорее всего в совокупности с неким набором приёмов, который является частью твоего опыта — своеобразным ноухау). Потому мне кажется, что направление паттернов стоит развивать — меняя и вырабатывая правильное к нему отношение.
Re[7]: как относитесь к подобному взгляду на паттерны?
У меня книга Гаммы (КГ) не вызвала никакой эйфории
Но после прочтения я стал применять паттерны из этой книги, хотя раньше таких конструкций не использовал вообще или использовал по-другому.
Т.е. я научился, приобрел новое знание.
Другой опыт применения паттернов я приобрел, когда стал обучать молодого программиста.
Человек был плохо знаком с ООП (думал, что ООП — это рисовать GUI в редакторе Delphi).
Дал ему КГ — человек стал мыслить другими категориями.
P.S. Кстати, примеры в КГ (построения редактора и т.п.) я не читал, так просмотрел немного. Ничего особо интересного для себя не увидел.
Поэтому не считаю, что эта книжка — описание дизайна текстового процессора с иллюстрациями в виде паттернов .
P.P.S. Опять скажу — паттерны просто еще один инстремент для разработчика, и не надо его ставить во главу угла.
... По ушам лупит "начальство" ...
Re[8]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Опять-таки — слишком категорично. G>Внутри тэга [ИМХО] я имею полное право быть категоричным, ведь так?
Как будто можно быть вне этого тега... Но вопрос то в другом — а стоит ли?
Re[9]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, AndreyFedotov, Вы писали:
AF>>> Опять-таки — слишком категорично. G>>Внутри тэга [ИМХО] я имею полное право быть категоричным, ведь так? AF> Как будто можно быть вне этого тега... Но вопрос то в другом — а стоит ли?
Что-то я не понял. Сравните (выделение мое):
G>>Как я уже говорил, [ИМХО]единственной полезной и реально работающей функцией паттерна я считаю иллюстративную функцию — применение терминологии и методологии паттернов позволяет упорядочить и структурировать изложение дизайна существующей системы, особенно если она сложна. Но не разработку.[/ИМХО] Бо все остальное заявленное про паттерны сильно конфликтует с моим личным, само собой, субъективным, опытом.
AF>Опять-таки — слишком категорично. Это одна из их функций. Основное — чему учат паттерну — умению "паттернировать" — т.е. выделять из кода некие решения — которые или можно затем тиражировать или же как минимум просто рассматривать их свойства и проектировать с их помощью систему — абстрагировавшись от лишних деталей, не имеющих отношения к работе выделенного паттерна. Действительно при проектировании мы обычно используем категории — отличные от перечисленных в книге Гаммы 12 паттернов...
Я вам рассказываю свое мнение и субъективный опыт, вы мне (я говорю о форме высказываний) — о том, "какова реальность" (со слов авторов книг по паттернам), причем упрекая меня в чрезмерной категоричности. Я, пожалуй, воздержусь от комментариев. Описание субъективного опыта всегда категорично, по другому быть не может. Привыкайте .
Re[10]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, Gaperton, Вы писали:
G>Я вам рассказываю свое мнение и субъективный опыт, вы мне (я говорю о форме высказываний) — о том, "какова реальность" (со слов авторов книг по паттернам), причем упрекая меня в чрезмерной категоричности. Я, пожалуй, воздержусь от комментариев. Описание субъективного опыта всегда категорично, по другому быть не может. Привыкайте .
А что мешает другим высказывать собственное мнение? Привыкайте...
Re: как относитесь к подобному взгляду на паттерны?
Никак, скорее всего писавший врядли использовал на практике что-то похожее из того что есть в паттернах, ну может фасад или адаптер . Скорее всего это просто оправдание его самому себе и другим, типа мы и сами умные. Умных много -- толковых мало .
Re[2]: как относитесь к подобному взгляду на паттерны?
Здравствуйте, byur, Вы писали:
B>Умных много -- толковых мало .
Ага. Правда приятно ведь бросаться умными словами?
Как тут уже говорилось, паттерны абсолютно не спасают от ошибок и плохого дизайна.
Поэтому и возникло это обсуждение
)
