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

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

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

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

как относитесь к подобному взгляду?

Здравствуйте, bugmaker, Вы писали:

B>если более конкретно, то знание паттернов просто упрощает разработку и использование кейс-средств
B>если при разработке кейс-средства не используются (ограничиваются лишь бумагой и карандашом) или используются по минимуму, то знание паттернов не является нужным

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

Hello, bugmaker!

Забыли еще одну штуку: терминология.
Т.е.когда я говорю о путях реализации, то фраза может выглядеть так: "Тут сделаем медиатор, через него будем фабрики регистрировать." И реализация становится понятной из простой фразы. А как иначе ? Растекаясь мыслью по древу описывать эти 2 стандартных решения ? Или "Помнишь, как мы в прошлый раз сделали. когда..." Или изобретать свою терминологию.
Паттерны нужны еще (или даже не "еще", а в первую очередь), чтобы разработчики на одном языке разговаривали, понимали друг друга. Помните, что с ростом числа разработчиков кол-во полезной работы не увеличивается линейно в основном из-за проблем коммуникаций. Дык вот он один из способов как-то уменьшить эти издержки — изучить паттерны и пользоваться ими.
А в части разработки, конечно, автор в чем-то прав. "Прочитал книжку про паттерны, понял, что использую паттерны".
Еще тут проскакивало : "Прочитал книгу про рефакторинг, понял, что использую."
Дык вот они все же в первую очередь ценны тем, что устанавливают терминологию. Сказал кто-то "модуль таблицы", а все поняли и не надо объяснять, что это "типа как в адо или типа как в дельфи"

Здравствуйте, bugmaker, Вы писали:

B>как относитесь к подобному взгляду?

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

Здравствуйте, 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 (уж на что брутальная вещь) использую всего несколько паттернов, на остальные потребности пока не вижу.
[ИМХО] чтение таких каталогов не лучшая трата времени. Книга гаммы и остальных — это другое, они описывают разработку законченной системы (!) [/ИМХО]

Здравствуйте, bugmaker, Вы писали:

B>как относитесь к подобному взгляду?
Положительно. Но не потому, что паттерны плохи сами по себе. Они никакие.
Однозначная польза от паттернов только одна — введение общей терминологии. Что успешно сводится на дерьмо, так как все сремяться придумать побольше разных "паттернов", и назвать их как нибудь по своему. Вот у нас в команде — как? Наши американские друзься изобрели несколько паттернов, из которых я запомнил два:
— multiple singleton (sic!)
— shared aggregation ( )
Рак мозга короче.

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

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

Здравствуйте, Курилка, Вы писали:


К>Отрицательно, ибо кейс — это одно, а паттерны могут очень запросто и без них использоваться.
К>Это просто набор типовых решений.
К>А ты уверен, что ты знаешь их все без прочтения книг и т.п.?
К>В смысле что представляешь себе все схемы и т.п.?
К>Думаешь, что ты в состоянии заменить кучи человеко-часов, которые люди (причём неслабые) потратили на проработку и отшлифовывание этих паттернов?
К>И почему завязка на кейс?
К>Вот допустим в C++ паттерны можно запросто использовать и редактируя просто в каком-нибудь notepad'е — никакие тут рисовалки или типа того не нужны, ибо паттерны не привязаны к ним, а есть общие концепции, ложащиеся довольно хорошо на современные языки программирования.
К>Всё, конечно, имхо.

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

Здравствуйте, Gaperton, Вы писали:

У меня книга Гаммы (КГ) не вызвала никакой эйфории
Но после прочтения я стал применять паттерны из этой книги, хотя раньше таких конструкций не использовал вообще или использовал по-другому.
Т.е. я научился, приобрел новое знание.

Другой опыт применения паттернов я приобрел, когда стал обучать молодого программиста.
Человек был плохо знаком с ООП (думал, что ООП — это рисовать GUI в редакторе Delphi).
Дал ему КГ — человек стал мыслить другими категориями.

P.S. Кстати, примеры в КГ (построения редактора и т.п.) я не читал, так просмотрел немного. Ничего особо интересного для себя не увидел.
Поэтому не считаю, что эта книжка — описание дизайна текстового процессора с иллюстрациями в виде паттернов .

P.P.S. Опять скажу — паттерны просто еще один инстремент для разработчика, и не надо его ставить во главу угла.

Здравствуйте, bugmaker, Вы писали:

...

B>если более конкретно, то знание паттернов просто упрощает разработку и использование кейс-средств
B>если при разработке кейс-средства не используются (ограничиваются лишь бумагой и карандашом) или используются по минимуму, то знание паттернов не является нужным

B>как относитесь к подобному взгляду?

Отрицательно, ибо кейс — это одно, а паттерны могут очень запросто и без них использоваться.
Это просто набор типовых решений.
А ты уверен, что ты знаешь их все без прочтения книг и т.п.?
В смысле что представляешь себе все схемы и т.п.?
Думаешь, что ты в состоянии заменить кучи человеко-часов, которые люди (причём неслабые) потратили на проработку и отшлифовывание этих паттернов?
И почему завязка на кейс?
Вот допустим в C++ паттерны можно запросто использовать и редактируя просто в каком-нибудь notepad'е — никакие тут рисовалки или типа того не нужны, ибо паттерны не привязаны к ним, а есть общие концепции, ложащиеся довольно хорошо на современные языки программирования.
Всё, конечно, имхо.

Здравствуйте, bugmaker, Вы писали:

B>почитав пару книг по паттернам проектирования пришел к выводу, что запоминать все это не имеет никакого смысла, ибо все что написано в книгах лишь описывает то, чем я и так занимаюсь без знания того, что "вот это такой-то паттерн"

B>то есть это как если бы описать естественный процесс ходьбы с указанием "вот здесь нога сгибается на 30 градусов, напрягаются икроножные и тазобедренные мышцы и т.д."
B>то есть это знание полезно для физиолога, но абсолютно ненужно для того кто делает все это — то есть просто ходит

Эти знания полезны для спортсмена, который не просто занимается этим, а занимается этим профессионально.

Здравствуйте, bugmaker, Вы писали:

B>...описать естественный процесс ходьбы с указанием "вот здесь нога сгибается на 30 градусов, напрягаются икроножные и тазобедренные мышцы и т.д."
B>то есть это знание полезно для физиолога, но абсолютно ненужно для того кто делает все это — то есть просто ходит

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

с опытом, обычно, приходят к тем приемам, которые описываются в книгах о патернах. Но это приходит после нескольких лет "косолапого" хождения... В книгах же обобщен накопленный опыт, осознание, которого позволяет избежать "косолапого" хождения.

Здравствуйте, bugmaker, Вы писали:

B>как относитесь к подобному взгляду?
Любая точка зрения имеет право на существование. Вокруг паттернов уже наврчено столько всего разного, столько уже состоялось плясок с бубнами, а так же столько раз их уже пытались выдать за очередную панацею — окончательное и бесповоротное решение всех проблем, что действительно иногда возникает впечатление, что паттерны вообще — большой мыльный пузырь.
Но по сути я с этой точкой зрения не согласен, так как на мой взгляд — это следствие ошибочного отношения к самим паттернам и их возможностям. Как мне кажется — паттерны, в том виде, каком их описывают в литературе, в реальных проектах применяются крайне редко (если вообще применяются), за редчайшими исключениями — вроде файбрики классов. Но они для этого и не предназначены! По-моему большинство паттернов представляют собой вовсе не готовые решения (а-ля кубик), а приёмы — которыми можно пользоваться, для создания подобных кубиков для реального проекта. На мой взгляд различие между паттернами проектирования и реальными проектными решениями — похоже на различие между простеньким интерфейсом и сложной реализацией — поддерживающей несколько таких интерфейсов. Но вот что действительно полезно — так это не столько сами паттерны — а процесс "патернирования" кода, т.е. систематического анализа кода с применением и рассмотрением таких понятий как связность, связанность, зацепление, отсветственность, множественность. Так как подобный процесс позволяет:
— выделить кубики, реально осмысленные в рамках проекта
— сформировать язык разработчиков проекта и документации, на основе выденных "кубиков"
— яснее представлять возможности и гибкость изменения проекта, в огромной степени проистекающую из кубиков, лежащих в основе архитектуры (дизайна проекта) и самой архитекутры (которая сама составлена из кубиков и является одним из кубиков)
— повысить эффективность общения, так как можно говорить о кубиках — имеющих чёткую цель и смысл, но в тоже время более высокоуровневых, чем отдельные классы.
— совершенствовать и развивать мышление проектировщиков и разработчиков, повышая уровень абсракции.
Впрочем это сугубо моя собственная точка зрения...

Здравствуйте, bugmaker, Вы писали:

B>1. зачем мне знать все и зачем мне знать, что "вот это — паттерн"?
B>2. идеального отшлифованного решения не существует, любое решение будет приспосабливаться под ситуацию и практически всегда отталкиваясь от ситуации можно прийти к наилучшему для этой ситуации решению,
B>ведь используемые технологии и бизнес-требования намного сильнее влияют на результат чем абстрактный шаблон, от которого предлагается отталкиваться
B>3. завязка на кейс, просто потому что это мне показалось единственным хорошим местом где это астрактное знание очень удобно применять

1. знание — сила
или ты предпочитаешь невежество?
И не обязательно знать "вот это — паттерн", есть и другие сценарии, например, ситуация, и логический вывод, что было бы полезно использовать паттерн X, т.к. он хорошо вписывается в условия задачи и подходит по смыслу

2. кто говорил про идеальное? Нет ничего идеального, но есть вещи очень приближенные к идеалу.
Или ты считаешь, что ты мегакулхацкер и заткнёшь за пояс всех Бучей, Гамм и т.д.?
Никто не говорит, что паттерны — это адепт. Просто это хорошо проработанные, опробованные и продуманные решения. А применять или нет — решать человеку. Но имхо, лучше иметь свободу выбора, чем изобретать в 100000-й раз колесо.

3. поясни. Не вижу какой-либо чёткой логической связи.

Здравствуйте, bugmaker, Вы писали:

B>почитав пару книг по паттернам проектирования пришел к выводу, что запоминать все это не имеет никакого смысла, ибо все что написано в книгах лишь описывает то, чем я и так занимаюсь без знания того, что "вот это такой-то паттерн"

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

B>то есть это как если бы описать естественный процесс ходьбы с указанием "вот здесь нога сгибается на 30 градусов, напрягаются икроножные и тазобедренные мышцы и т.д."

Нога человека, а как же, например, животные? Так и здесь... Вот есть например паттерн MVC. Он описывает решение для общего случая. Но ведь приложение может иметь как гуевое представление, так и Web-представление. Потому существуют специальные каталоги паттернов для конкретных областей.

B>то есть это знание полезно для физиолога, но абсолютно ненужно для того кто делает все это — то есть просто ходит

Когда тебя начнут доканывать что мол походка нелепая, физиолог скажет, а ты типа не сгибай ноги-то на 90 градусов
Вывод: знание полезно...

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

B>если более конкретно, то знание паттернов просто упрощает разработку и использование кейс-средств
B>если при разработке кейс-средства не используются (ограничиваются лишь бумагой и карандашом) или используются по минимуму, то знание паттернов не является нужным

Знание паттернов и упрощает и ускоряет разработку. В какой-то мере обеспечивает единство подхода при разработке. И вообще, изучение подобного рода конструкций — это как математика. А математика — гимнастика ума

B>как относитесь к подобному взгляду?

Не согласен. Хотя это и так понятно...

ps: Я время от времени перечитываю книги по паттернам. И узнаю для себя что-то новое...

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, bugmaker, Вы писали:

G>Наши американские друзься изобрели несколько паттернов, из которых я запомнил два:
G>- multiple singleton (sic!)
G>- shared aggregation ( )
G>Рак мозга короче.
Занятно. Узнать, что это такое, можно?

G>Паттерны это не инструмент проектирования. Вранье чистой воды. Ну не думает грамотный проектировщик над тем, какой бы ему паттерн привернуть, чтобы все заработало. Вместо этого он анализирует функционал объектов и отношения между ними, не до паттернов ему. Так скажем, он работает на более детальном уровне. А вот когда дизайн закончен, вы найдете в нем много паттернов, в том числе и известных. Парадокс, однако .
Паттерны — это оружие проектировщика. Хороший проектировщик, действительно, не просто знает о них, он ими думает. Можно их назвать не по буржуйски — паттернами, а просто приемы работы. И этими приемами и умением их применять, как раз, и ценен дизайнер или архитектор. И именно этим они отличаются от других разработчиков. Ведь именно кардиолог лечит сердце, хотя и остальные врачи оканчивали мед. институт. Специализация, великая вещь. И у проектировщиков есть своя специализация.
В основном, это, действительно, постигается только опытом, и именно опыт определяющая вещь. К сожалению, многие у нас включают свою гениальность не обладая знаниями и опытом. И результат получается соответствующий. Может вы с этим не встречались, а я встречался. Переписывались значительные куски кода, из-за того, что приделать новую функциональность было невозможно. Или для какой-то функциональности, приходилось пробегать по 20 мб сырцам. Или процедура на 10000 строк. Если бы человек хотя бы знал, что такое рекурсивная декомпозиция. Ошибки дизайна и архитектуры, очень тяжелые ошибки.

С уважением, Gleb.

Здравствуйте, Gaperton, Вы писали:

G>Паттерны это не инструмент проектирования. Вранье чистой воды. Ну не думает грамотный проектировщик над тем, какой бы ему паттерн привернуть, чтобы все заработало. Вместо этого он анализирует функционал объектов и отношения между ними, не до паттернов ему. Так скажем, он работает на более детальном уровне. А вот когда дизайн закончен, вы найдете в нем много паттернов, в том числе и известных. Парадокс, однако .

Не могу судить однозначно — я не грамотный проектировщик. Но разве паттерны не описывают некоторые часто используемые отношения между объектами?
Естественно проектировщик анализирует функционал и отношения и прочее, но когда он знает о проверенном типовом решении (паттерн?) — обязательно его применит.
Не будет же проектировщик на каждом проекте изобретать все отношения заново. А уж как назвать это типовое решение, паттерн или непаттерн, — дело десятое.

G>Однозначная польза от паттернов только одна — введение общей терминологии. Что успешно сводится на дерьмо, так как все сремяться придумать побольше разных "паттернов", и назвать их как нибудь по своему. Вот у нас в команде — как? Наши американские друзься изобрели несколько паттернов, из которых я запомнил два:
G>- multiple singleton (sic!)
G>- shared aggregation ( )
G>Рак мозга короче.

"ибо сказано не плодите сущностей сверх необходимости"
Разве рак мозга в паттернах?
Каталог паттернов очень полезная штука — всего сам не придумаешь, будь ты трижды гениален.
А расширит этот каталог только время — я, например, из каталога Гаммы и Co (уж на что брутальная вещь) использую всего несколько паттернов, на остальные потребности пока не вижу.

P.S. А multiple singleton судя по всему какой-то страшный хардкор

Здравствуйте, bugmaker, Вы писали:

B>как относитесь к подобному взгляду?
Отрицательно.
1. Разработчику, который только что усвоил, что такое абстракция и инкапсуляция, трудно объяснить как все это применять. Все проходили через элементарные ошибки проектирования. В данном случае, можно сильно сократить данный период. Когда только начинал непонимал всей сути ООП, много дров наломал. Но самое главное, что этого не понимал что это дрова. И не только в этой области. Сейчас есть ясное понимание, что если берешься за новую область, сначало прочитай теорию, и только после этого изучай практику. Только тогда дается ясное понимание того, как это работает, что ты делаешь, и оссобенно, как ты это будешь делать.
2. Общая терминология. Когда ты говоришь, что ты здесь построишь фабрику классов, становится понятно что такое фабрика классов, для чего она здесь, и что другие от этого будут иметь.
3. Удобно посылать. Когда надо доказать свою точку зрения, можно всегда послать на ссылку, с гордым видом высказывая: "Это не я так утверждаю, а наука".
4. Паттерны обычно описываются не просто как теоретические решения, но и как примеры на практике, а также их оссобенности в той, или иной ситуации. Всегда можно найти что-то интересное.

Не менее полезны (а может более) антипаттерны.
Вообще, шаблонов несколько больше чем только проектирования. Сейчас, например, читаю Data Movement Patterns, нахожу интересные решения, и абсолютно знаю, что если мне придется делать offline клиента, то я знаю как их сделаю, и что не совершу ошибок в архитектуре. А ошибки архитектуры, много стоят. Так что лучше один раз прочитать, чем потом платить.

С уважением, Gleb.

Здравствуйте, Alex Reyst, Вы писали:

AR>Здравствуйте, bugmaker, Вы писали:

B>>как относитесь к подобному взгляду?

AR>Основные моменты уже высказаны, я, возможно, немного повторю предыдущих ораторов .

AR>Вы постоянно высказываете свое отрицательное отношение к литературе с изложением накопленного другими опыта.
да нет
может просто в паре топиков, что то такое было

AR>Извините, но каким бы вы не были замечательным программистом сейчас, я никогда не поверю, что вы родились с этими знаниями, а не получили их в результате серии "проб и ошибок". И что, вы предлагаете всем шабивать себе на голове шишки, наступая на грабли? Нет, спасибо — я никому не порекомендую подобную "методу". О свойствах цианистого калия лучше узнавать не на собственном опыте .

AR>Кроме того, я не поверю, что весь имеющийся опыт вы получили лично, а не обмениваясь знаниями с другими. Тогда почему такое отрицательное отношение к "концентрированному" изложению такого опыта уже даже не одного поколения программистов? Извините, но мне видится в этом только лишь желание самоутвердиться, отрицая влияние опыта других людей в вашем собственном становлении как программиста.

просто иногда хочется задать провокационные вопросы и послушать чужие мнения

Здравствуйте, bugmaker, Вы писали:

B>просто иногда хочется задать провокационные вопросы и послушать чужие мнения

Напровоцировал минусов на свою голову .

Здравствуйте, kavlad, Вы писали:

K>P.S. А multiple singleton судя по всему какой-то страшный хардкор

Не знаю, что имел ввиду Gaperon, но и тут на РСДН
нечто встречается :
http://www.rsdn.ru/Forum/?mid=836998&flat=0

Автор: yxiie
Дата: 05.10.04

Да простит меня yxiie

Здравствуйте, Gaperton, Вы писали:

G>Я вам рассказываю свое мнение и субъективный опыт, вы мне (я говорю о форме высказываний) — о том, "какова реальность" (со слов авторов книг по паттернам), причем упрекая меня в чрезмерной категоричности. Я, пожалуй, воздержусь от комментариев. Описание субъективного опыта всегда категорично, по другому быть не может. Привыкайте .
А что мешает другим высказывать собственное мнение? Привыкайте...

Здравствуйте, bugmaker, Вы писали:


B>как относитесь к подобному взгляду?

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

Здравствуйте, kavlad, Вы писали:

K>Здравствуйте, bugmaker, Вы писали:

B>>как относитесь к подобному взгляду?

K>Во-первых, это флейм и в Delphi размещать его не надо.
K>Во-вторых, ты просто ходишь потому, что ходишь много-много лет. Многие начинающие разработчики только ползают. Паттерны — это ходунки, которые учат ходить.
K>В-третьих, с паттернами проще проектировать — это еще одни "кирпичики", только покрупнее, чем просто классы.
K>В-третьих с половиной, так проще понимать чужие решения дизайна — общая терминология и все-такое прочее.
K>В-четвертых, врядли один разработчик способен самостоятельно придумать все решения даже из одной работы "банды четырех", а работ по паттернам уже достаточно много — т.е. обмен знаниями.

ну во первых это не в дельфи
во вторых я просто спросил навеяло

Здравствуйте, bugmaker, Вы писали:

B>ну во первых это не в дельфи

Сорри, Delphi зачитался

Здравствуйте, bugmaker, Вы писали:

B>как относитесь к подобному взгляду?

Этот взгляд я уже прокомментировал здесь

Автор: Alex Reyst
Дата: 05.05.04

.

Здравствуйте, bugmaker, Вы писали:

B>как относитесь к подобному взгляду?

Основные моменты уже высказаны, я, возможно, немного повторю предыдущих ораторов .

Вы постоянно высказываете свое отрицательное отношение к литературе с изложением накопленного другими опыта.

Извините, но каким бы вы не были замечательным программистом сейчас, я никогда не поверю, что вы родились с этими знаниями, а не получили их в результате серии "проб и ошибок". И что, вы предлагаете всем шабивать себе на голове шишки, наступая на грабли? Нет, спасибо — я никому не порекомендую подобную "методу". О свойствах цианистого калия лучше узнавать не на собственном опыте .

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

Здравствуйте, s.ts, Вы писали:


ST>Забыли еще одну штуку: терминология.

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

Здравствуйте, kavlad, Вы писали:

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

Здравствуйте, Gaperton, Вы писали:

G>....отталкиваясь от паттернов (как пытаются делать многие, по моим наблюдениям) ...
G>... А соответствие системы известным паттернам — не критерий, или по крайней мере не первичный критерий.
G>... хотя бы на одно законченное описание целостного подхода к ОО дизайну с применением паттернов...
G>В людях, которые верят в магию паттернов

Со всем согласен.
Я старался сделать акцент на том, что паттерны не ключевая вещь, не панацея и не надо ставить их во главу угла. Но видимо не получилось

G>Пардон? Синглтон — "проверенное типовое решение"? Есть варианты "непроверенных" способов сделать что-то подобное? Пул разделяемых объектов — это проверенное решение? Да вы просто не сможете без него обойтись, если он понадобится. Когда речь заходит о паттернах как о "проверенных решениях", я просто не понимаю, о чем речь. Реализован-то паттерн может быть как угодно, так?

Под словом "проверенные" понималось ранее придуманные и использованные, т.е. это к вопросу о придумывании новых паттернов.

G>[ИМХО] чтение таких каталогов не лучшая трата времени. Книга гаммы и остальных — это другое, они описывают разработку законченной системы (!) [/ИМХО]

Это и есть каталог паттернов и примеры их использования. Разве не так?

G>Вывод? Паттерны это просто имена для часто всречающихся конфигураций функционала в ОО системе, и все. Объяснить коллеге ваш подход к дизайну удобно используя терминологию общеупотребимых паттернов.

Когда я читал книгу Гаммы, узнал много новых "часто всречающихся конфигураций функционала в ОО системе". Разве это не одна из функций паттернов?

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, bugmaker, Вы писали:

B>>как относитесь к подобному взгляду?
GZ>Отрицательно.
GZ>1. Разработчику, который только что усвоил, что такое абстракция и инкапсуляция, трудно объяснить как все это применять.

Разработчику, который только что усвоил, что такое абстракция и инкапсуляция, не нужно объяснить как все это применять. Если он усвоил, то он знает как использовать полученные знания.

GZ>... если берешься за новую область, сначало прочитай теорию, и только после этого изучай практику. Только тогда дается ясное понимание того, как это работает, что ты делаешь, и оссобенно, как ты это будешь делать.

-1
Чистая теория так же вредна, как и практика без теории. Я вообше не стал бы разделять эти понятия. Для того, чтобы чему-то научиться, выработать какие-то навыки необходимо это делать. Приведу аллегорию: Сколько бы книг о лошадях ты не прочитал, ты не научишься ездить на лошади, пока на нее не сядешь.

GZ>2. Общая терминология. Когда ты говоришь, что ты здесь построишь фабрику классов, становится понятно что такое фабрика классов, для чего она здесь, и что другие от этого будут иметь.

+1
Согласен

GZ>3. Удобно посылать. Когда надо доказать свою точку зрения, можно всегда послать на ссылку, с гордым видом высказывая: "Это не я так утверждаю, а наука".

-1
То, что так утверждает наука, лично для меня не является убедительным аргументом при доказательстве. Это скорее повод к размышлению.
Аристотель в свое время утверждал, что у паука 6 ног и тяжелые предметы падают быстрее, чем легкие.
Истину, чтобы она не стала догмой, всегда нужно подвергать сомнению и перепроверять, независимо от того, насколько авторитетного источника она исходит: Аристотеля, Александреску или Фаулера.

GZ>Не менее полезны (а может более) антипаттерны.

+1

Здравствуйте, dshe, Вы писали:

GZ>>1. Разработчику, который только что усвоил, что такое абстракция и инкапсуляция, трудно объяснить как все это применять.

D>Разработчику, который только что усвоил, что такое абстракция и инкапсуляция, не нужно объяснить как все это применять. Если он усвоил, то он знает как использовать полученные знания.
Не знает!!! И это касается не только касается данной области. Можно описать любоет решение как некоторую точку в многомерном пространстве проблем. И неопытный разработчик (а иногда и опытный) не всегда видит, все измерения и их шкалу и во что, это решение выльется. Эти вещи познаются только предыдущим опытом или экспериментом. И учатся на ошибках. Если разработчик будет тупо плодить интерфейсы, и инкапсулировать кучу различных ненужных вещей, то он доведет всю идею до маразма, и не сможет построить эффективное приложение. Такое приложение невозможно будет сопровождать.
Вообще, паттерны проектирования — это всего лишь маленькая часть того, что должен знать разработчик (особенно если он работает самостоятельно). И не стоит смешивать умение применения паттернов и декомпозицию сущностей. Они очень похожи, но это не одно и то же.

GZ>>... если берешься за новую область, сначало прочитай теорию, и только после этого изучай практику. Только тогда дается ясное понимание того, как это работает, что ты делаешь, и оссобенно, как ты это будешь делать.

D>-1
D>Чистая теория так же вредна, как и практика без теории. Я вообше не стал бы разделять эти понятия. Для того, чтобы чему-то научиться, выработать какие-то навыки необходимо это делать. Приведу аллегорию: Сколько бы книг о лошадях ты не прочитал, ты не научишься ездить на лошади, пока на нее не сядешь.
+1. И чем это отличается от того что я до этого написал?

GZ>>3. Удобно посылать. Когда надо доказать свою точку зрения, можно всегда послать на ссылку, с гордым видом высказывая: "Это не я так утверждаю, а наука".

D>-1
D>То, что так утверждает наука, лично для меня не является убедительным аргументом при доказательстве. Это скорее повод к размышлению.
D>Аристотель в свое время утверждал, что у паука 6 ног и тяжелые предметы падают быстрее, чем легкие.
D>Истину, чтобы она не стала догмой, всегда нужно подвергать сомнению и перепроверять, независимо от того, насколько авторитетного источника она исходит: Аристотеля, Александреску или Фаулера.
Интересная точка зрения.
1. Если бы каждый физик, или тот же Циолковский, начал бы доказывать теорию Ньютона, то мы бы никогда не построили ракету. Если бы Энштейн не создал теорию Относительности, мы бы никогда не узнали, что теория Ньютона не верна. Принято считать, что теория Ньютона всегда верна при определенных условиях. Точно так же и в программировании, нужно знать и пользоваться верной теорией, и не поддвергать ее сомнению. Иначе наделаешь кучу ошибок, или пройдешь уже по пройденному пути. Но знать ее границы. А догм пока нет, как и серебрянной пули.
2. В последнее время очень трудно отделить маркетинг от теории. Поэтому стоит выбрать источники, которым ты доверяешь на 100%.
3. Если мне подойдет человек, и скажет, что принял решение по той или иной причине, укажит источники (или эти источники общеизвестны), то такой человек мне нравится больше, чем человек который скажет: "А так круче". Решение второго придется проверять и перепроверять, то есть выполнять его функции.
4. Стоит выбрать, чем ты в данный момент занимаешься, производством программных продуктов или наукой.

С уважением, Gleb

Здравствуйте, kavlad, Вы писали:

G>>[ИМХО] чтение таких каталогов не лучшая трата времени. Книга гаммы и остальных — это другое, они описывают разработку законченной системы (!) [/ИМХО]
K>Это и есть каталог паттернов и примеры их использования. Разве не так?
Зависит от точки зрения. На мой взгляд (имхо), от простого каталога паттернов эту книгу отличает то, что она довольно связно рассказывает о дизайне текстового процессора. Заостряя моменты на удачных примерах решения дизайнерских проблем. Т. е. это не каталог паттернов с иллюстрацией на примере текстового процессора, а описание дизайна текстового процессора с иллюстрациями в виде паттернов . Разница существенная. Паттерны здесь не главное — главное, что вам показывают проблемы в дизайне и их решения (оформленные в виде паттернов; авторы книги, впрочем, выставляют все иначе). При этом, вам не рассказывают, как авторы пришли к этим решениям (!). Читать ее, меж тем, все равно интересно; с моей точки зрения, главная заслуга авторов — им удалось показать красоту ОО дизайна, что он может быть одновременно легок, прост, функционален и красив. Очень жизнеутверждающая и мотивирующая к качественной работе книга.

G>>Вывод? Паттерны это просто имена для часто всречающихся конфигураций функционала в ОО системе, и все. Объяснить коллеге ваш подход к дизайну удобно используя терминологию общеупотребимых паттернов.
K>Когда я читал книгу Гаммы, узнал много новых "часто всречающихся конфигураций функционала в ОО системе". Разве это не одна из функций паттернов?
Возможно. Как вы считаете, зная описание этих паттернов у вас получится их воспроизводить в своем дизайне? А может, вы уже давно это делаете, но просто не смотрели на собственный дизайн под таким углом, и находитесь под впечатлением открывшейся картины? У меня эйфория от "открывшихся возможностей" после прочтения Гаммы (5 лет назад) прошла за 2 дня, когда я понял, что ничего, собственно, нового в процесс моего дизайна паттерны не привносят, я рассуждаю при дизайне совсем другими категориями (сценарии-функции-отношения-потоки данных), а паттерны у нея внутре все равно воспроизводятся с завидной регулярностью, причем даже те, названий которых я не знаю. Да и хрен с ними, в конце концов, пускай .

Как я уже говорил, [ИМХО]единственной полезной и реально работающей функцией паттерна я считаю иллюстративную функцию — применение терминологии и методологии паттернов позволяет упорядочить и структурировать изложение дизайна существующей системы, особенно если она сложна. Но не разработку.[/ИМХО] Бо все остальное заявленное про паттерны сильно конфликтует с моим личным, само собой, субъективным, опытом.

Здравствуйте, Gaperton, Вы писали:

G>Зависит от точки зрения. На мой взгляд (имхо), от простого каталога паттернов эту книгу отличает то, что она довольно связно рассказывает о дизайне текстового процессора. Заостряя моменты на удачных примерах решения дизайнерских проблем. Т. е. это не каталог паттернов с иллюстрацией на примере текстового процессора, а описание дизайна текстового процессора с иллюстрациями в виде паттернов . Разница существенная. Паттерны здесь не главное — главное, что вам показывают проблемы в дизайне и их решения (оформленные в виде паттернов; авторы книги, впрочем, выставляют все иначе). При этом, вам не рассказывают, как авторы пришли к этим решениям (!). Читать ее, меж тем, все равно интересно; с моей точки зрения, главная заслуга авторов — им удалось показать красоту ОО дизайна, что он может быть одновременно легок, прост, функционален и красив. Очень жизнеутверждающая и мотивирующая к качественной работе книга.
Может быть черезчур категорично, но с основной мыслю согласен. Дествительно пожалуй самое интересное, не само по себе прменение паттерна, а причины, по которым был выбран тот или иной паттерн. Особенно — на ранней стадии развития системы. Тут очень многое зависит от интуиции проектировщика — от его умения предвидеть, в какую сторону будут изменяться требования к системе и как это будет отражатся на коде. Вот способ потому способ, как выбирается подходящий паттерн (рассматривая паттерн в широком смысле — как некое выделенное из кода и изолированное от лишних деталей решение, не обязательно известное или встречающееся у других) — действительно пожалуй важнее и интереснее самого паттерна. Так как именно от его эффективности будет зависеть частота и интенсивность изменения кода.

K>>Когда я читал книгу Гаммы, узнал много новых "часто всречающихся конфигураций функционала в ОО системе". Разве это не одна из функций паттернов?
G>Возможно. Как вы считаете, зная описание этих паттернов у вас получится их воспроизводить в своем дизайне? А может, вы уже давно это делаете, но просто не смотрели на собственный дизайн под таким углом, и находитесь под впечатлением открывшейся картины? У меня эйфория от "открывшихся возможностей" после прочтения Гаммы (5 лет назад) прошла за 2 дня, когда я понял, что ничего, собственно, нового в процесс моего дизайна паттерны не привносят, я рассуждаю при дизайне совсем другими категориями (сценарии-функции-отношения-потоки данных), а паттерны у нея внутре все равно воспроизводятся с завидной регулярностью, причем даже те, названий которых я не знаю. Да и хрен с ними, в конце концов, пускай .
Согласен. Почему то такие вещи, как callback вызов, интерфейс, полиморфизм, выделение в модуль — хотя очевидно являются типовыми решениями и используются даже чаще чем самые распространённые паттерны (вроде файбрики или файбричного метода), но по какой то загадочной причине к паттернам не относятся. С моей точки зрения всё ООП — это не что иное, как наука о паттернах (т.е. о неких приёмах, дающих чёткий, прогнозируемый и воспроизводимый результат), т.к. на мой взгляд программирование таки состоит почти сплошь из паттернов разных логических уровней (например, класс или функция по моему очевидные паттерны, но распространены так широко, что о них в таком качестве никто и не думает — они воспринимаются столь же естественно, как воздух).

G>Как я уже говорил, [ИМХО]единственной полезной и реально работающей функцией паттерна я считаю иллюстративную функцию — применение терминологии и методологии паттернов позволяет упорядочить и структурировать изложение дизайна существующей системы, особенно если она сложна. Но не разработку.[/ИМХО] Бо все остальное заявленное про паттерны сильно конфликтует с моим личным, само собой, субъективным, опытом.
Опять-таки — слишком категорично. Это одна из их функций. Основное — чему учат паттерну — умению "паттернировать" — т.е. выделять из кода некие решения — которые или можно затем тиражировать или же как минимум просто рассматривать их свойства и проектировать с их помощью систему — абстрагировавшись от лишних деталей, не имеющих отношения к работе выделенного паттерна. Действительно при проектировании мы обычно используем категории — отличные от перечисленных в книге Гаммы 12 паттернов. Но если разобраться — мы используем множество собственных паттернов (например те же потоки данных ты ведь наверняка рассматриваешь и обдумываешь не просто так — изолированно ото всего — а скорее всего в совокупности с неким набором приёмов, который является частью твоего опыта — своеобразным ноухау). Потому мне кажется, что направление паттернов стоит развивать — меняя и вырабатывая правильное к нему отношение.

Здравствуйте, AndreyFedotov, Вы писали:

AF> Опять-таки — слишком категорично.
Внутри тэга [ИМХО] я имею полное право быть категоричным, ведь так?

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, AndreyFedotov, Вы писали:

AF>> Опять-таки — слишком категорично.
G>Внутри тэга [ИМХО] я имею полное право быть категоричным, ведь так?

Как будто можно быть вне этого тега... Но вопрос то в другом — а стоит ли?

Здравствуйте, AndreyFedotov, Вы писали:

AF>Здравствуйте, Gaperton, Вы писали:

G>>Здравствуйте, AndreyFedotov, Вы писали:

AF>>> Опять-таки — слишком категорично.
G>>Внутри тэга [ИМХО] я имею полное право быть категоричным, ведь так?
AF> Как будто можно быть вне этого тега... Но вопрос то в другом — а стоит ли?
Что-то я не понял. Сравните (выделение мое):

G>>Как я уже говорил, [ИМХО]единственной полезной и реально работающей функцией паттерна я считаю иллюстративную функцию — применение терминологии и методологии паттернов позволяет упорядочить и структурировать изложение дизайна существующей системы, особенно если она сложна. Но не разработку.[/ИМХО] Бо все остальное заявленное про паттерны сильно конфликтует с моим личным, само собой, субъективным, опытом.

AF>Опять-таки — слишком категорично. Это одна из их функций. Основное — чему учат паттерну — умению "паттернировать" — т.е. выделять из кода некие решения — которые или можно затем тиражировать или же как минимум просто рассматривать их свойства и проектировать с их помощью систему — абстрагировавшись от лишних деталей, не имеющих отношения к работе выделенного паттерна. Действительно при проектировании мы обычно используем категории — отличные от перечисленных в книге Гаммы 12 паттернов...

Я вам рассказываю свое мнение и субъективный опыт, вы мне (я говорю о форме высказываний) — о том, "какова реальность" (со слов авторов книг по паттернам), причем упрекая меня в чрезмерной категоричности. Я, пожалуй, воздержусь от комментариев. Описание субъективного опыта всегда категорично, по другому быть не может. Привыкайте .

Здравствуйте, byur, Вы писали:

B>Умных много -- толковых мало .

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