Здравствуйте, 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
Чушь.
Re[2]: Думать надо не шаблонами, думать надо головой
Здравствуйте, 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 — ну вы поняли...
Re[3]: Думать надо не шаблонами, думать надо головой
A>Любая мысль, доведенная до абсурда, является абсурдом.
Воистину так.
Я видел пару проектов сделанных 1:1 по книге Фаулера. Это было ужасно.
Чтобы сделать 1 сущность в системе нужно было сделать кажись 6 интерфейсов, пару фабрик и все это
влычить в какие-то абстракции. На вопрос — зачем собстно все это? ответ был не менее замечательный-
потому что так круто и вона как написано у Фаулера. Исправляли потом это довольно долго...
Еще один вариант — вынесение констант в настройки. Видел код, где в настройки вынесли все,
включая размер килобайта. Ну и правда ведь — вдруг у заказчика другой размер...
В общем мозг-то его завсегда полезно включать. И при использовании паттернов тоже.
Здравствуйте, fplab, Вы писали:
F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования: F>http://arbinada.com/main/node/30
Полезным или вредным может быть только то, КАК шаблоны применяются (или не применяются).
Булыжник тоже может быть полезен при разработке софта, если есть место и навык для его применения.
Здравствуйте, fplab, Вы писали:
F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования: F>http://arbinada.com/main/node/30
>Не сомневаюсь, что для человека, близко знакомого с основами ООП, вынести общую логику в абстрактный класс-предок является таким же естественным действием, как чистка зубов перед сном.
Не сомневаюсь, что для человека, близко знакомого с правилами надёжного повторного использования кода, вынесение коллегой общей логики в абстрактный класс-предок вместо того, чтобы общий алгорити оформить в виде отдельного класса, окончится естественным действием в виде чистки зубов этого коллеги булыжником.
ps. Ну, ессно, я перегибаю палку, но суть фразы согласуется с ответами выше.
После рассуждений выносится решение о необходимости виртуализации вызовов путем построения иерархии, аналогичной существующей иерархии классов и добавлении новых методов в неё. То есть реализации шаблона Visitor.
Одной этой фразы для оценки текста уже достаточно.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, C0s, Вы писали:
C0s>Не сомневаюсь, что для человека, близко знакомого с правилами надёжного повторного использования кода, вынесение коллегой общей логики в абстрактный класс-предок вместо того, чтобы общий алгорити оформить в виде отдельного класса, окончится естественным действием в виде чистки зубов этого коллеги булыжником.
Поскольку алгоритм это не сущность, а действие, чистить зубы надо именно за вынесение его в класс.
Здравствуйте, dsorokin, Вы писали:
D>Мне статья понравилась. Творческий дух не выносит шаблонов, а индустрии шаблоны нужны. Таки да, "мыслить шаблонно" — это ругательство.
Хвала небесам — наконец, нашелся человек, который понял то, что автор статьи хотел донести. Я уж почти отчаялся Те, кто в танке — сосредоточтесь хоть чуточку, прочтите внимательно название темы.
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Re[3]: Думать надо не шаблонами, думать надо головой
Здравствуйте, fplab, Вы писали:
F>Хвала небесам — наконец, нашелся человек, который понял то, что автор статьи хотел донести. Я уж почти отчаялся Те, кто в танке — сосредоточтесь хоть чуточку, прочтите внимательно название темы.
Чтобы понять то, что хотел донести автор, надо мыслить весьма нешаблонно.
А мы в танке, так что звиняйте.
Здравствуйте, fplab, Вы писали:
F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:
F>http://arbinada.com/main/node/30
Лично я всегда воспринимал всю эту "теорию" паттернов исключительно как некое унифицирование терминологии. В общем то мелочь конечно, но всё же иногда полезная — в этом я не согласен с автором статьи.
А вот о ситуации когда эта книжка попадает в руки полного новичка я как-то никогда не думал. И тут возможно автор статьи прав... Если кто-то воспринимает эту классификацию не как способ "узнать как обычно обзывают подобный кусок кода", а как справочник "как написать код", то это очень печально...
Re[2]: Думать надо не шаблонами, думать надо головой
Здравствуйте, Pavel_Agurov, Вы писали:
P_A>Я видел пару проектов сделанных 1:1 по книге Фаулера. Это было ужасно.
Вы недооцениваете Фаулера. С его помощью можно так же легко обосновать почему этот конкретный паттерн в конкретном месте применён ошибочно.
Re[3]: Думать надо не шаблонами, думать надо головой
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, Steamus, Вы писали:
S>>Человек абсолютно не понял что такое шаблон Стратегия
W>А Вы понимаете, что такое шаблон Стратегия? W>Я вот тоже не понимаю... Раньше понимал — теперь не понимаю.
Да, я понимаю что такое шаблон Стратегия. Шаблон важный, быть может даже самый важный из всех. Ибо по своей сути лежит в основе такого подхода как проектирование от интерфейсов. По существу, он также лежит в основе зачем-то переназванного шаблона Dependency injection. Такие фреймворки как Спринг по большому счёту созданы для удобной утилизации этого шаблона.
Re[4]: Думать надо не шаблонами, думать надо головой
Здравствуйте, Pavel_Agurov, Вы писали:
A>>Любая мысль, доведенная до абсурда, является абсурдом.
P_A>Воистину так.
P_A>Я видел пару проектов сделанных 1:1 по книге Фаулера. Это было ужасно. P_A>Чтобы сделать 1 сущность в системе нужно было сделать кажись 6 интерфейсов, пару фабрик и все это P_A>влычить в какие-то абстракции.
Первое, чему постоянно учит Фаулер, так это тому, что проектирование штука сложная и прямое копирование подходов одной задачи в другой возможно далеко не всегда. И потом, Фаулер преимущественно не акцентируется на базовых шаблонах GoF. Фаулер скорее рассматривает более высокоуровневые подходы, советуя (советуя!) обратить внимание на места, которые во многих проектах стали тонкими. И потому их лучше бы изначально оформить/декларировать правильно, пусть на первый взгляд и несколько избыточно. В дальнейшем это окупится сторицей.
Из этого никак не следует, что для вывода "Привет мир" на экран следует реализовывать фабрику строки, оформив её как реализацию интерфейса с промежуточным абстрактным классом.
Здравствуйте, fplab, Вы писали:
F>Может это и баян, но нашел достаточно старый текст о бесполезности шаблонов проектирования:
Паттерны полезны как универсальные способы борьбы со сложностью, но универсальными являются только простые паттерны, а именно:
1) Скрывание избыточных деталей (паттерн Фасад)
2) Стандартизация (паттерн Адаптер)
3) Скрывание выбора варианта обработки (паттерн Стратегия)
4) Решение проблемы комбинаторного взрыва числа вариантов обработки (паттерн Мост)
Это базовые кирпичики, на которых основывается практически любое упрощение кода.
К более сложным паттернам я отношусь скептически. Т.к. в силу своей сложности они не являются универсальными и соответственно с высокой вероятностью попытка их использования вместо упрощения решения задачи приводит к подгонке задачи под паттерн и усложнению решению. Кроме того ряд общепризнанных сложных паттернов гарантированно приводят к усложнению решения (например, паттерн Декоратор), т.е. на самом деле это антипаттерны.
