LINUX.ORG.RU

Паттерны.

 


3

3

Народ, откуда столько НЕНАВИСТИ к паттернам в программировании?

Пробежался тут по последним темам.

For example, in the OO world you hear a good deal about «patterns». I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough — often that I'm generating by hand the expansions of some macro that I need to write. — P. Graham

'Patterns mean «I have run out of language.»' — Rich Hickey

Ну и там хор подпевал, как обычно, и всё в таком духе. Вообще, сколько себя помню, на ЛОРе термин «паттерны проектирования» всегда был синонимом какого-то вселенского зла.

Но ведь если разобраться, то «паттерны» так или иначе присутствуют просто ВЕЗДЕ. В градостроительстве, архитектуре, механике, инженерии, электронике, транспорте, аэрокосмосе, музыке, спорте, кулинарии, литературе, поэзии, живописи, медицине, физике, математике, геологии, географии, добыче ископаемых, сельском хозяйстве, военном деле, государственном управлении, экономике, финансах, социологии, в людских взаимоотношениях, наконец! Человечество повсеместно использует стандартные подходы/сценарии/решения, проверенные годами. И к ним мы относимся совершенно нормально. Почему мы, например, услышав секвенцию II-V-I в «Лунной сонате», не говорим Бетховену: «Чувак, you've run out of harmony!» Почему, увидев четырёхстопный ямб у Пушкина, не предъявляем: «Чувак, да у тебя же a sign of trouble в стихах!»

Почему только будучи применёнными к программированию паттерны вызывают столь лютую ненависть?


Почему только будучи применёнными к программированию паттерны вызывают столь лютую ненависть?

Потому, что их слишком часто не умеют готовить, но при этом активно используют. Культ Карго во всей красе.

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

forCe
()
Ответ на: комментарий от iZEN

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

А можно какой-нибудь расхожий пример, как лисп-DSL позволяет решать задачи предметной области? А то слышу на ЛОРе постоянно про language oriented programming, но жизненными примерами оно что-то не изобилует. Желательно какую-нибудь real life предметную область, не абстрактную алгебру и теорию категорий.

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

BYHYRT
() автор топика
Ответ на: комментарий от DELIRIUM

<@Gliptic> FloatFactoryFactory.getInstance(FloatFactoryFactory.defaultInstanceDescriptionString).getFactory(Locale.getLocale(«en-US»)).createBuilder().setString(«1.5»).getResult()

Ну вот об этом я и говорил, что якобы повсеместные FactoryFactory — это что-то из разряда городских легенд, побасенок и шуточек в курилке :)

BYHYRT
() автор топика
Ответ на: комментарий от anonymous

Это уже терминальная стадия ООП головного мозга.

Прошу прощения, но при чём тут ООП?

Вселенная состоит из объектов, а объекты состоят из паттернов.

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

BYHYRT
() автор топика
Ответ на: комментарий от KennyMinigun

Человеку свойственно не любить то, что он не знает/не умеет.

Вот-вот, мне тоже иногда кажется, что 90% ненависти — из-за непонимания, что такое паттерны, зачем они нужны и где их следует применять

BYHYRT
() автор топика
Ответ на: комментарий от Deleted

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

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

BYHYRT
() автор топика
Ответ на: комментарий от mamba_namba_karamba

Суть треда: «Программирование. Искусство и наука или ремесло?»

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

BYHYRT
() автор топика
Ответ на: комментарий от BYHYRT

90% ненависти — из-за непонимания, что такое паттерны, зачем они нужны и где их следует применять

А еще неправильное применение паттернов это антипаттерн. Не помню как называется, правда.

KennyMinigun ★★★★★
()
Ответ на: комментарий от ak380618

Потому что это не паттерны, а синтаксис языка.

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

Ямб, хорей, анапест, дактиль, амфибрахий — это ритмические паттерны.

Секвенции, каденции, формы музыкальных произведений, аккорды, гармонические и мелодические построения — это музыкальные паттерны. У музыкантов-электронщиков даже есть такой инструмент — pattern sequencer :)

BYHYRT
() автор топика
Ответ на: комментарий от dave

Шаблоны - добро и зло одновременно. Все зависит от ситуации.

Ура :) вас бы пораньше в этот топик.

BYHYRT
() автор топика
Ответ на: комментарий от BYHYRT

А можно какой-нибудь расхожий пример, как лисп-DSL позволяет решать задачи предметной области?

Лишпег ничего не решает, кроме факториалов.

А DSL-и применяются сплошь и рядом. Регулярные выражения (например, в JavaScript или Perl) - типичный eDSL. GNU Make - DSL. Hibernate - DSL. Весь современный C++ состоит из eDSLей (смотри на тот же Boost). Это давно уже мейнстрим, просто говнари только сейчас очухались и пытаются присвоить лавры себе.

anonymous
()
Ответ на: комментарий от anonymous

Регулярные выражения (например, в JavaScript или Perl) - типичный eDSL. GNU Make - DSL. Hibernate - DSL. Весь современный C++ состоит из eDSLей (смотри на тот же Boost).

Ну, это-то понятно. Только эти все DSL чисто технической направленности. А если верить лисперам, они прямо задачи предметной области решают. Ну вот взять такую область как логистика (управление потоками — грузов, пассажиров, да вообще чего угодно). Было бы интересно взять упрощённую модель и прикинуть, как мог бы выглядеть DSL на лиспе и DSL на Java, например.

BYHYRT
() автор топика
Ответ на: комментарий от BYHYRT

Стандартный подход на Java — смоделировать понятия предметной области как классы, а связи между ними — как связи между классами (наследование, ассоциация/агрегация/композиция). Бизнес-логика реализуется методами бизнес-классов либо специальными бизнес-сервисами.

Это уже DSL или ещё нет? И почему?

BYHYRT
() автор топика
Ответ на: комментарий от BYHYRT

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

Говнолисперы ничего не решают. А в промышленности, конечно же, DSL в предметных областях полно. На те же CAD-ы посмотри, там DSL на DSL сидит и DSL погоняет.

такую область как логистика

Увы, тут я полный ноль, так что ничем не могу помочь.

anonymous
()
Ответ на: комментарий от BYHYRT

Ямб, хорей, анапест, дактиль, амфибрахий — это ритмические паттерны.

Секвенции, каденции, формы музыкальных произведений, аккорды, гармонические и мелодические построения — это музыкальные паттерны. У музыкантов-электронщиков даже есть такой инструмент — pattern sequencer :)

Судя по этим сентенциям, до тебя не дошло, что такое паттерны в программировании.

ak380618
()
Ответ на: комментарий от BYHYRT

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

Делал DSL для разбора языков, в нем описывались лексика, синтаксис и местами семантика. Много занимался анализом данных в разных форматах, было удобно.

Делал DSL для работы с SQL базами данных. Получился скобчатый SQL с бэкендами к mssql, psql и mysql. DSL вводил единый синтаксис, который мог по-разному транслироваться для каждой БД, а если БД что-то не умела, раскладывал вычисления между сгенерированным клиентским lisp-кодом и сгенерированным серверным SQL-кодом. Одно время было много работы прямо с БД, я бы тоже назвал это специфической предметной областью.

Делал DSL для сервера генерации отчетов, позволял описывать сущности отчетов (источники данных, столбцы, фильтры) и комбинировать их между собой.

И еще делал DSL для системы выявления событий из потока данных, в нем описывались правила определения событий. ГИС. События были типа «10:00 - 10:30, машина проехала 50 км», "... - ..., машина стояла", "... - ..., машина заправилась на 200 литров" и т.д.

Сколько попутно было написано и/или использовано eDSL, не сосчитать.

Всеми DSL кроме первой пользовался не только я, но и люди, далекие от лиспа и иногда программирования вообще.

Ну вот взять такую область как логистика (управление потоками — грузов, пассажиров, да вообще чего угодно). Было бы интересно взять упрощённую модель и прикинуть, как мог бы выглядеть DSL на лиспе и DSL на Java, например.

DSL на яве выглядит как класс «логистика», это же очевидно. В продвинутом варианте — фреймворк «логистика».

staseg ★★★★★
()
Ответ на: комментарий от BYHYRT

DSL на Java это обычно XML-формат. Реализация какая угодно может быть - кодогенерация, интерпретация, рефлексия...

anonymous
()

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

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

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

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

И называлась та религия ООП, ее священники - ООП-учеными, а те самые косяки и аномалии прозвали паттернами.

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

anonymous
()
Ответ на: комментарий от anonymous

паттерны - признак убогости языка

Но ведь в лиспе и хаскеле есть паттерны. Следовательно, это --- убогие языки?

anonymous
()
Ответ на: комментарий от anonymous

Но ведь в лиспе и хаскеле есть паттерны.

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

anonymous
()
Ответ на: комментарий от anonymous

Если затупишь слишком сильно над этими элементарными вопросами - возвращайся за списком литературы.

В студию.

anonymous
()
Ответ на: комментарий от anonymous

Не может быть там паттернов

Как же так? А это тогда что? REPL, DSL, JIT, Adaptive Model, Alternative Tokenization, Annotation, BNF, Class Symbol Table, Closure, Construction Builder, Context Variable, Decision Table, Delimiter-Directed Translation, Dependency Network, Dynamic Reception, Embedded Interpretation, Embedded Translation, Embedment Helper, Expression Builder, Foreign Code, Function Sequence, Generation Gap, Literal Extension, Literal List, Literal Map, Macro, Method Chaining, Model Ignorant Generation, Model-Aware Generation, Nested Closure, Nested Function, Nested Operator Expression, Newline Separators, Notification, Object Scoping, Parse Tree Manipulation, Parser Combinator, Parser Generator, Production Rule System, Recursive Descent Parser, Regex Table Lexer, Semantic Model, State Machine, Symbol Table, Syntax-Directed Translation, Templated Generation, Textual Polishing, Transformer Generation, Tree Construction

Дружок, да твой лисп просто кишит паттернами!

anonymous
()

Паттерны это профессиональные приёмы, использующиеся в программировани. Студенты и теоретики их могут не понимать, они и не для них сделаны. У опытных программистов паттерны вызывают уважение и радость.

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

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

OKAY. Но ведь тогда Abstract factory, Builder, Factory method, Prototype, Singleton, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor -- не паттерны.

Следовательно, в Java нет паттернов.

anonymous
()
Ответ на: комментарий от anonymous

Но ведь тогда Abstract factory, Builder, Factory method, Prototype, Singleton, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor — не паттерны.

Это паттерны.

anonymous
()
Ответ на: комментарий от anonymous

А теперь обоснуй свое утверждение.

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

anonymous
()
Ответ на: комментарий от anonymous

Так приведи же это определение.

«Christopher Alexander says, „Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice“. Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context»

anonymous
()
Ответ на: комментарий от anonymous

Неверно. Корректное определение ниже:

A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science.

Вывод: паттерны применимы ко всей области computer science, включая ООП, ФП и LISP.

Слив засчитан.

anonymous
()
Ответ на: комментарий от anonymous

Корректное определение ниже

Источник?

Слив засчитан.

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

anonymous
()
Ответ на: комментарий от anonymous

Observer — паттерн, описанная руками state machine — тоже паттерн, но многое из твоего первого списка — не паттерн (устойчивая конструкция из языковых конструкций), а языковая конструкция. Цикл for в жабке — не паттерн.

PolarFox ★★★★★
()
Ответ на: комментарий от anonymous

wikipedia

Недостоверный источник. К тому же определение в Википедии ссылается на мою цитату.

То есть твое определение неверное.

anonymous
()
Ответ на: комментарий от anonymous

Приведи источник своего определения.

И где в нем сказано, что паттерны применимы ТОЛЬКО к ООП, и не применимы к LISP и ФП?

anonymous
()
Ответ на: комментарий от anonymous

Приведи источник своего определения.

Gamma et al., 1994, Design Patterns

И где в нем сказано, что паттерны применимы ТОЛЬКО к ООП

Там же и сказано: «Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors».

anonymous
()
Ответ на: комментарий от anonymous

„Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice“

Определение ничего не утверждает о применимости паттернов к ООП или ФП.

Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context

Следствием определения является то, что паттерны применимы к ООП.

Следствием определения не является то, что паттерны неприменимы к ФП и LISP.

У тебя грубая логическая ошибка в рассуждениях. Итак, обоснование не приведено. Слив все-таки засчитывается. Хорошего дня.

anonymous
()
Ответ на: комментарий от anonymous

Определение ничего не утверждает о применимости паттернов к ООП или ФП.

Ты привел цитату Christopher Alexander, а не Gamma et all.

Слив все-таки засчитывается.

Я уже объяснил, как засчитывается слив. Вот ты, похоже, уже близко, засуетился. Почему бы просто не признать правду? Это не будет сливом.

anonymous
()
Ответ на: комментарий от anonymous

Грубая логическая ошибка — достаточное условие для слива.

Не согласен — докажи, что из приведенного определения следует неприменимость паттернов проектирования к ФП и LISP.

anonymous
()
Ответ на: комментарий от anonymous

докажи, что из приведенного определения следует неприменимость паттернов проектирования к ФП и LISP

Ты привел не то определение.

anonymous
()

<<Если в вашей программе используются паттерны проектирования, то скорее всего вы используете недостаточный уровень абстракции>>

Debasher ★★★★★
()
Ответ на: комментарий от Debasher

в вашей программе используются

паттерны проектирования,

На ноль поделить помочь, или сам справишься?

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.