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

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

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

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

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

Hello, bugmaker!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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