Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:

http://arbinada.com/main/node/30

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

F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:

F>http://arbinada.com/main/node/30

Пробежал глазами.

-------------------------------------------
>...Не сомневаюсь, что для человека, близко знакомого с основами ООП, вынести общую логику в абстрактный класс-предок является таким же естественным действием, как чистка зубов перед сном. Обычно планирование этой операции занимает в голове минуты 2-3 местного машинного времени. Видимо за его, времени, недостатком, мне и не приходило в голову обозвать эту операцию "Стратегией".
-------------------------------------------

Человек абсолютно не понял что такое шаблон Стратегия. И видимо не догадывается как разумнее проектировать систему опираясь на интерфейсы.

-------------------------------------------
>...Постойте, коллеги, какие шаблоны на С++, какие ещё шаблоны на C#? Оказывается, шаблоны сыграли с программистским сообществом злую шутку: они оказались еще и языкозависимыми.
-------------------------------------------

Угу. Похоже он вообще странный человек.

-------------------------------------------
>... "Thinking in patterns". В переводе на русский язык — "Мыслить шаблонно".
-------------------------------------------
Схохмил так схохмил.

Зачем это выковыривать из глубин инета? 5 лет прошло, быть может человеку давно стыдно за этот глуповатый подростковый текст.

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

F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:

F>http://arbinada.com/main/node/30

Чушь.

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

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

F>>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:

F>>http://arbinada.com/main/node/30

P_A>Чушь.

Любая мысль, доведенная до абсурда, является абсурдом.
Если человек прочитал ТОЛЬКО книжку про паттерны и больше ничего другого, то он действительно жалок.
Но если эта книжка стоит в ряду многих других прочитанных, то я бы сказал, что она полезна.

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

fp>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:
fp>http://arbinada.com/main/node/30

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

А моя практика доказывает обратное. Кто прав ?

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

Повторю сообщения выше — то, что описывает автор, паттерном "Стратегия" не является.

Третье разочарование оказалось фатальным: я прочел, что Гамма защитил научную (!) диссертацию по этой теме.

Действительно, это камень (да нет, булыжник !) в огород паттернов !

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

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

На днях я наткнулся в сети на книгу с названием, претендующим на звание самого абсурдного из встречавшихся. Оно звучит как "Thinking in patterns". В переводе на русский язык — "Мыслить шаблонно".

Да уж, перевод на сто баллов !

Когда-то, еще совсем недавно, привычка шаблонно мыслить считалась если не ругательством в инженерном сообществе, то признанием серьезной ограниченности специалиста. Мол, этого инженера надо посадить решать типовые задачи с 9 утра до 6 вечера, большего с него не взять, а теперь целые книжки пишут о том, как стать специалистом с шаблонным мышлением. Но думать надо не шаблонами, думать надо головой.

Мыслить нешаблонно хорошо где-нибудь в сфере искусств, а в программерском ремесле этому места нет.
С 9 утра до 6 вечера я решаю типовые задачи, а нешаблонно мне приходится мыслить полчаса в день от силы.

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

F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:

F>http://arbinada.com/main/node/30

Я тоже считаю шаблолны вредной штукой, но по другой причине. Шаблоны полезны только как общий язык для описания архитектуры, можно сказать "фабрика" и все тебя поймут. Обратной стороной является то, что люди, которые знают о существовании шаблонов, иногда начинают решать задачи по принципу "if all you have is a hammer, everything looks like a nail", то есть просто подбирают шаблон под задачу, вместо того, что-бы решать задачу. Прочитали у Фаулера про CQRS — делаем следующий проект на CQRS, прочитали про event sourcing — ну вы поняли...

A>Любая мысль, доведенная до абсурда, является абсурдом.

Воистину так.

Я видел пару проектов сделанных 1:1 по книге Фаулера. Это было ужасно.
Чтобы сделать 1 сущность в системе нужно было сделать кажись 6 интерфейсов, пару фабрик и все это
влычить в какие-то абстракции. На вопрос — зачем собстно все это? ответ был не менее замечательный-
потому что так круто и вона как написано у Фаулера. Исправляли потом это довольно долго...

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

В общем мозг-то его завсегда полезно включать. И при использовании паттернов тоже.

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

F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:
F>http://arbinada.com/main/node/30
Полезным или вредным может быть только то, КАК шаблоны применяются (или не применяются).
Булыжник тоже может быть полезен при разработке софта, если есть место и навык для его применения.

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

F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:
F>http://arbinada.com/main/node/30

>Не сомневаюсь, что для человека, близко знакомого с основами ООП, вынести общую логику в абстрактный класс-предок является таким же естественным действием, как чистка зубов перед сном.

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

ps. Ну, ессно, я перегибаю палку, но суть фразы согласуется с ответами выше.

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

F>http://arbinada.com/main/node/30

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

Одной этой фразы для оценки текста уже достаточно.

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

C0s>Не сомневаюсь, что для человека, близко знакомого с правилами надёжного повторного использования кода, вынесение коллегой общей логики в абстрактный класс-предок вместо того, чтобы общий алгорити оформить в виде отдельного класса, окончится естественным действием в виде чистки зубов этого коллеги булыжником.

Поскольку алгоритм это не сущность, а действие, чистить зубы надо именно за вынесение его в класс.

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

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

D>Мне статья понравилась. Творческий дух не выносит шаблонов, а индустрии шаблоны нужны. Таки да, "мыслить шаблонно" — это ругательство.

Хвала небесам — наконец, нашелся человек, который понял то, что автор статьи хотел донести. Я уж почти отчаялся Те, кто в танке — сосредоточтесь хоть чуточку, прочтите внимательно название темы.

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

F>Хвала небесам — наконец, нашелся человек, который понял то, что автор статьи хотел донести. Я уж почти отчаялся Те, кто в танке — сосредоточтесь хоть чуточку, прочтите внимательно название темы.

Чтобы понять то, что хотел донести автор, надо мыслить весьма нешаблонно.
А мы в танке, так что звиняйте.

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

F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:

F>http://arbinada.com/main/node/30

Лично я всегда воспринимал всю эту "теорию" паттернов исключительно как некое унифицирование терминологии. В общем то мелочь конечно, но всё же иногда полезная — в этом я не согласен с автором статьи.

А вот о ситуации когда эта книжка попадает в руки полного новичка я как-то никогда не думал. И тут возможно автор статьи прав... Если кто-то воспринимает эту классификацию не как способ "узнать как обычно обзывают подобный кусок кода", а как справочник "как написать код", то это очень печально...

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

S>Человек абсолютно не понял что такое шаблон Стратегия

А Вы понимаете, что такое шаблон Стратегия?
Я вот тоже не понимаю... Раньше понимал — теперь не понимаю.

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

P_A>Я видел пару проектов сделанных 1:1 по книге Фаулера. Это было ужасно.
Вы недооцениваете Фаулера. С его помощью можно так же легко обосновать почему этот конкретный паттерн в конкретном месте применён ошибочно.

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

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

S>>Человек абсолютно не понял что такое шаблон Стратегия

W>А Вы понимаете, что такое шаблон Стратегия?
W>Я вот тоже не понимаю... Раньше понимал — теперь не понимаю.

Да, я понимаю что такое шаблон Стратегия. Шаблон важный, быть может даже самый важный из всех. Ибо по своей сути лежит в основе такого подхода как проектирование от интерфейсов. По существу, он также лежит в основе зачем-то переназванного шаблона Dependency injection. Такие фреймворки как Спринг по большому счёту созданы для удобной утилизации этого шаблона.

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

A>>Любая мысль, доведенная до абсурда, является абсурдом.

P_A>Воистину так.

P_A>Я видел пару проектов сделанных 1:1 по книге Фаулера. Это было ужасно.
P_A>Чтобы сделать 1 сущность в системе нужно было сделать кажись 6 интерфейсов, пару фабрик и все это
P_A>влычить в какие-то абстракции.

Первое, чему постоянно учит Фаулер, так это тому, что проектирование штука сложная и прямое копирование подходов одной задачи в другой возможно далеко не всегда. И потом, Фаулер преимущественно не акцентируется на базовых шаблонах GoF. Фаулер скорее рассматривает более высокоуровневые подходы, советуя (советуя!) обратить внимание на места, которые во многих проектах стали тонкими. И потому их лучше бы изначально оформить/декларировать правильно, пусть на первый взгляд и несколько избыточно. В дальнейшем это окупится сторицей.

Из этого никак не следует, что для вывода "Привет мир" на экран следует реализовывать фабрику строки, оформив её как реализацию интерфейса с промежуточным абстрактным классом.

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

F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:

Паттерны полезны как универсальные способы борьбы со сложностью, но универсальными являются только простые паттерны, а именно:

1) Скрывание избыточных деталей (паттерн Фасад)
2) Стандартизация (паттерн Адаптер)
3) Скрывание выбора варианта обработки (паттерн Стратегия)
4) Решение проблемы комбинаторного взрыва числа вариантов обработки (паттерн Мост)

Это базовые кирпичики, на которых основывается практически любое упрощение кода.

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

04.10.2011 10:16, Здравствуйте, fplab :
> Хвала небесам — наконец, нашелся человек, который понял то, что автор
> статьи хотел донести. Я уж почти отчаялся Те, кто в танке —
> сосредоточтесь хоть чуточку, прочтите внимательно название темы.

А автор что-то хотел донести? Нет, реально, просветите нас. Только вот
не нужно про сабжевую банальность.

Автор (да и вы тоже) смутно догадывается, где собака порылась, но
внятного ответа почему паттерны проектирования такая гадость,
дать не может. Мы с детства в паттернах. Детский сад? Переходя дорогу,
смотрим сначала налево, потом направо. Школа? Дают задачу, дают пример
ее решения и дают кучу заданий на самостоятельное решение подобных
задач. И так по каждой теме. Мы приходим в ВУЗ. Чем нас пичкают на
лекциях? Паттернами доказательств: прямое, от противного, методом
исключения. Потом на каждой дисциплине, аксиоматика которых также
укладывается в один паттерн (его дают на старших курсах), мы из паттерна
аксиом выводим все новые и новые теоремы с помощью паттернов
доказательств. На проработках продолжаются школьные паттерны -- пример
решения и задания на самостоятельное решение. Да в нас за нашу жизнь
вкладывается столько паттернов, что мы должны быть "зашаблонизированы"
по самые ушки.

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

Здравствуйте, Ромашка, Вы писали:

Р>Так почему нам все эти паттерны жить и творить не мешают

Потому что паттерны работают, когда есть рутина, сильная повторяемость и сходность, механика, моторика.

Р>, а паттерны
Р>проектирования заставляют вполне вменяемых и умных людей писать код, на
Р>который без слез смотреть невозможно?

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

Хорошие инженеры, кстати, тоже творчески мыслят. А по паттернам работают токари, слесари.

12.11.2011 22:06, Здравствуйте, DorfDepp :
> Потому что паттерны работают, когда есть рутина, сильная повторяемость и
> сходность, механика, моторика.
> А создание софта есть творческая дизайнерская деятельность с большим
> творческим потенциалом. Попробуй научи дизайнера работать по шаблонам.
> Некоторые могут, только их "работа" не представляет никакой
> художественной ценности.

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

> Хорошие инженеры, кстати, тоже творчески мыслят. А по паттернам работают
> токари, слесари.

Инженеры тоже работают по паттернам и для творческого мышления паттерны
ни разу не помеха. Я не слышал, чтобы, скажем, венгерская нотация
ограничивала кого-то в творчестве. А нотация это есть суть паттерн
именования переменных. Что отличает паттерны проектирования от остальных
паттернов, которыми мы пользуемся, но которые нам совершенно не мешают?

Здравствуйте, Ромашка, Вы писали:

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

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

Потому что взрослые вменяемые люди увидев новое слово "паттерн" почему-то приняли его за метод действия (до некоторой степени даже я не исключение). Почему так случилось — не знаю. Может быть, потому, что традиционно проектирование ПО считается чем-то запредельно сложным, чем владеют только гуру, а тут такой подарок: гуру поделились знаниями. Ну а дальше как всегда: ученики-то в немалой части далеко не гуру, да ещё и очень даже "идолопоклонники" — вот и превратили набор наблюдений в фетиш. Ещё можно провести аналогию с культом карго: если я возьму в руки портфель и надену профессорский пиджак, то я стану профессором.

Кстати, я сам отметился на этом поприще (посмотри моё первое сообщение на RSDN), правда, меня по первому времени GoF привлекли именно "близостью к жизни" — большая часть описанного так или иначе встречалась мне до 2001-го года, когда я познакомился с GoF. Действительно, много из того, что было в книге, я уже синтезировал сам. О, думаю, авторы — свои люди! Правда, сейчас уже такие дискуссии без приступа тоски читать не могу: взрослые люди серьёзно обсуждают детали различий какой-нибудь Strategy и Memento.

ИМХО, паттерны GoF (и не только) можно как-то использовать, если задаться целью именно исследования паттернов, как таковых. Скажем, для того, чтобы выделить какие-то общие закономерности в принимаемых решениях, или ещё для чего-то. Пытаться их прямо применять (по сути дела, инвертируя остановку задачи на выделение паттернов) — невероятно сложная задача, гораздо сложнее, чем синтез подходящего решения в некоем заданном контексте. Собственно, как всегда оно происходит, когда вещи переворачиваются с ног на голову.

12.11.2011 22:45, Здравствуйте, Геннадий Васильев :
> Паттерны — это вторичная конструкция, первичен выбранный набор действий.


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

Еще один вопрос. Почему, когда используются паттерны, смешивается
абстракция предметной области с абстракцией паттерна? Откуда лезут
всякие Helper-ы, Mapper-ы и прочее, чего вроде в модели быть не должно
ибо строится совсем не модель паттернов?

Здравствуйте, Ромашка, Вы писали:

Р>12.11.2011 22:45, Здравствуйте, Геннадий Васильев :
>> Паттерны — это вторичная конструкция, первичен выбранный набор действий.

Р>А вот это интересная мысль. Если взять аналогию с производной
Р>(паттерном), то мы можем каким-то образом оценить только поведение
Р>функции (метода), но не можем оценить значение в конкретной точке (сам
Р>метод), потому что в первообразной (реализации метода) обязательно
Р>выскочит константа (неопределенность)? Что-то сумбурно как-то.

Да нет, как раз, ИМХО, удачная аналогия: паттерн — как производная. А весь цимус реальности — в константах.

Р>Еще один вопрос. Почему, когда используются паттерны, смешивается
Р>абстракция предметной области с абстракцией паттерна? Откуда лезут
Р>всякие Helper-ы, Mapper-ы и прочее, чего вроде в модели быть не должно
Р>ибо строится совсем не модель паттернов?

ИМХО, по двум причинам. Первая — потому что агрегаты, которые получаются при декомпозиции, нужно как-то называть (давать классу некоторое имя). А вторая — потому что литература по паттернам одновременно предлагает некоторую более или менее единообразную систему терминов как раз для обозначения таких агрегатов.

U> Кроме того ряд общепризнанных сложных паттернов гарантированно приводят к усложнению решения (например, паттерн Декоратор), т.е. на самом деле это антипаттерны.

декоратор — это тот же мост, но вид сбоку

когда систему пилили на кусочки было применение моста, а когда из напиленных кусочков начинаем собирать обратно — получаем декоратора

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

S>Первое, чему постоянно учит Фаулер, так это тому, что проектирование штука сложная и прямое копирование подходов одной задачи в другой возможно далеко не всегда.

+1, побаяню: http://www.rsdn.ru/forum/philosophy/2568701.1.aspx

Автор: Дм.Григорьев
Дата: 02.07.07

Здравствуйте, Steamus, Вы писали:
S>-------------------------------------------
>>...Постойте, коллеги, какие шаблоны на С++, какие ещё шаблоны на C#? Оказывается, шаблоны сыграли с программистским сообществом злую шутку: они оказались еще и языкозависимыми.
S>-------------------------------------------

S>Угу. Похоже он вообще странный человек.
Видимо не только он. Есть и другие:
Вот в прошлом тысячелетии Норвиг сочинил
Да и мнение, что шаблоны имени вдовы председателя Мао ("банда четырёх") -- просто способ борьбы с недостатками языка, считает достаточно много народа.