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

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

LVV>>И сколько опыта у вас тогда было?
Ops>Года 2-4, сейчас точно не помню.

Вот! Похоже, что это именно тот порог, когда народ начинает понимать.
Если, конечно, народ реально работает...

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

LVV>
LVV>Вот! Похоже, что это именно тот порог, когда народ начинает понимать.
LVV>Если, конечно, народ реально работает...

Только казалось бы, при чем тут паттерны?

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

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

LVV>>
LVV>>Вот! Похоже, что это именно тот порог, когда народ начинает понимать.
LVV>>Если, конечно, народ реально работает...

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

А мой студент в результате переписывания как раз тотально паттерны и применил — ибо система нуждалась в непрерывном развитии.
Поэтому жизнь заставила...

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

Ops>Когда я первый раз почитал про паттерны, оказалось, что я большую часть из того же ГоФ знаю и вовсю применяю

Когда я первый раз прочитал про паттерны, я понял, что о них я знал еще тогда, когда не было паттернов

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

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

Ops>>Когда я первый раз почитал про паттерны, оказалось, что я большую часть из того же ГоФ знаю и вовсю применяю

PD>Когда я первый раз прочитал про паттерны, я понял, что о них я знал еще тогда, когда не было паттернов

Господа, вы же профессионалы, просто достаньте линейки и померяйтесь.

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

A>Первый вопрос: как находить суть паттернов?
Паттерн это копипаста неустранимая средствами выбранного языка.
В похожих языках (C# и Java) паттерны похожи. В сильно разных (C# и haskell) сильно разные.
В языках с качественным метапрограммированием найти паттерны не просто. Ибо трудно придумать копипасту которую не устранить метапрограммированием.

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

A>>Первый вопрос: как находить суть паттернов?
WH>Паттерн это копипаста неустранимая средствами выбранного языка.
WH>В похожих языках (C# и Java) паттерны похожи. В сильно разных (C# и haskell) сильно разные.
WH>В языках с качественным метапрограммированием найти паттерны не просто. Ибо трудно придумать копипасту которую не устранить метапрограммированием.

Паттерн это не копипаста. Вопрос не в том, можно ли устранить паттерн, вопрос в том, можно ли устряняя паттерн сделать код более понятным тем, кто с ним работает.
Если просто так устранять паттерны на том основании, что это копипаста(непонятный термин), то окажется так, что программу сможет прочесть только компилятор.

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

Отсюда ясно, что единсвенный код, где нет паттернов это "DoAll"

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

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

Правильные вопросы про паттерны — как ими пользоваться и почему они собственно вознимают.

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

I>Вот так, что бы кода было много и весь на метапрограммировании, и не было паттернов — это в принципе невозможно. Любая более менее устойчивая структура будет паттерном. Например в языках с метапрограммированием паттерны нужно искать в библиотеках макросов. Понятно, что метапрограммирование не устраняет паттерны. Эти самые паттерны просто кочуют в библиотеки макросов и компилятор.
Ох. А сколько паттернов перекочевало в код компиляторов обычных языков, никогда не задумывался? Вызов метода паттерн. Вызов виртуального метода немного другой паттерн. Цикл снова паттерн. Итп.
Если что-то уехало в библиотеку или компилятор, то это уже не паттерн.
Ибо повторяющегося с маленькими отличиями куска кода больше нет.

I>Вообще паттерны это естественный этап накопления опыта. Во всех без исключения областях деятельности человека есть эти самые паттерны. Скажем "сицилианская защита" в шахматах это обычный паттерн. Или например "королевский гамбит" это целое семейство паттернов.
Не верная аналогия. В шахматах мы не можем засунуть паттерны в компилятор.
Но если не отвлекаться от программирования, то в процессе работы над новой задачей со временем начинают появляться очень похожие куски кода.
Если язык позволяет, то они устраняются методами языка.
Язык с метапрограммированием может устранить что угодно.
А вот у всех остальных языков рано или поздно встречается паттерн который ни в функцию ни в класс не засунуть.
И такие паттерны начинают жить своей жизнью отравля жизнь разработчикам.

I>Правильные вопросы про паттерны — как ими пользоваться и почему они собственно вознимают.
Возникают они из-за несоответствия выбранного языка и предметной области. Языки общего назначения, как правило, ничего общего с предметной областью не имеют. Вот на них паттерны и расцветают пышным цветом.

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

К сожалению, в общем случае, это возможно только если есть метапрограммирование.

Я имел ввиду паттерны программирования типа тех, которые описаны в GoF. А вы про какие говорите? Почему паттерн это копипаста? Копипаста организации кода? Приведите пример на каком нибудь языке программирование с метапрограммированием, как вы выполните определенную задачу для которой в обычном языке необхоимо применить некий паттерн. Самый распространенный (частой звучащее название) паттерн это фабрика, давайте на его примере.

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

A>Я имел ввиду паттерны программирования типа тех, которые описаны в GoF. А вы про какие говорите?
Да про них и говорю.

A>Почему паттерн это копипаста? Копипаста организации кода? Приведите пример на каком нибудь языке программирование с метапрограммированием, как вы выполните определенную задачу для которой в обычном языке необхоимо применить некий паттерн. Самый распространенный (частой звучащее название) паттерн это фабрика, давайте на его примере.
Была куча почти одинакового кода:

class Factory 
{
  public virtual CreateWidget (name : string) : Widget {
    Widget (name)
  }
  public virtual CreateWorker (name : string, tasks : int) : Worker {
    Worker (name, tasks)
  }
}

class MyFactory : Factory 
{
  public override CreateWidget (name : string) : Widget {
    MyWidget (name)
  }
  public override CreateWorker (name : string, tasks : int) : Worker {
    MyWorker (name, tasks)
  }
}

Применили макрос и она исчезла.

[Nemerle.DesignPatterns.AbstractFactory (Widget, Worker)]
class Factory {}

[Nemerle.DesignPatterns.AbstractFactory (
  Override (MyWidget, Widget),
  Override (MyWorker, Worker)
)]
class MyFactory : Factory {}

https://github.com/rsdn/nemerle/wiki/Design-patterns

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

Здравствуйте, Alllie, Вы писали:
A>Первый вопрос: как находить суть паттернов?
мне кажется, наиболее точный перевод слова паттерн в данном случае это узор.
вот вы смотрите снежинки падают. они все разные, но во многом похожи. В мозку у вас автоматом проходит процесс кластеризации данных и выявления их характеристик. вы замечаете, что бывают большие и маленькие, бывают, там, не знаю, с дыркой и без дырки. когда у вас накапливается статистика, вы даете знакомым узорам имена. то же самое с паттернами программирования. есть какие-то часто встречающиеся решения, которым логично дать некие термины. чтобы каждый не давал им свои имена и избежать путаницы, договорились об именах для подобных решений. антипаттерны — это просто имена для часто встречающихся хреновых решений.

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

I>>Вот так, что бы кода было много и весь на метапрограммировании, и не было паттернов — это в принципе невозможно. Любая более менее устойчивая структура будет паттерном. Например в языках с метапрограммированием паттерны нужно искать в библиотеках макросов. Понятно, что метапрограммирование не устраняет паттерны. Эти самые паттерны просто кочуют в библиотеки макросов и компилятор.
WH>Ох. А сколько паттернов перекочевало в код компиляторов обычных языков, никогда не задумывался? Вызов метода паттерн. Вызов виртуального метода немного другой паттерн. Цикл снова паттерн. Итп.

WH>Если что-то уехало в библиотеку или компилятор, то это уже не паттерн.

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

WH>Ибо повторяющегося с маленькими отличиями куска кода больше нет.

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

В любом случае фокус — в приложении оставляем "DoAllApp.Run()" и, внезапно, весь код у нас в библиотеке. Следовательно паттернов там нет

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

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

Как структурируешь код, такие паттерны там и появятся.

WH>Но если не отвлекаться от программирования, то в процессе работы над новой задачей со временем начинают появляться очень похожие куски кода.
WH>Если язык позволяет, то они устраняются методами языка.
WH>Язык с метапрограммированием может устранить что угодно.

Да, я выше показал пример — "App.Run()"

WH>А вот у всех остальных языков рано или поздно встречается паттерн который ни в функцию ни в класс не засунуть.
WH>И такие паттерны начинают жить своей жизнью отравля жизнь разработчикам.

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

I>>Правильные вопросы про паттерны — как ими пользоваться и почему они собственно вознимают.
WH>Возникают они из-за несоответствия выбранного языка и предметной области. Языки общего назначения, как правило, ничего общего с предметной областью не имеют. Вот на них паттерны и расцветают пышным цветом.

В DSL паттернов не меньше. Возьми DSL навроде SQL или RegExp — полно паттернов.
Более того, любой ДСЛ обладает таким свойством — например BNF имеет кучу паттернов.

WH>К сожалению, в общем случае, это возможно только если есть метапрограммирование.

Особенно, если закрывать глаза на паттерны в библиотеке макров.

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

WH>Применили макрос и она исчезла.
WH>

WH>[Nemerle.DesignPatterns.AbstractFactory (Widget, Worker)]
WH>class Factory {}

WH>[Nemerle.DesignPatterns.AbstractFactory (
WH>  Override (MyWidget, Widget),
WH>  Override (MyWorker, Worker)
WH>)]
WH>class MyFactory : Factory {}
WH>

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

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

I>Это значит, что паттерны там и надо искать. А ты предлагаешь закрывать глаза на состояние кода в библиотеке.

Как это следует из того что я написал не представляю.

Паттерн вызов метода

push значение_1
push значение_2
call procedure

переехал в компилятор в единственном экземпляре. И уже компилятором размножается по всей программе.

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

push значение_1
push значение_2
call procedure

Засунут в компилятор почти во всех языках программирования.

I>Как структурируешь код, такие паттерны там и появятся.
Для того чтобы у тебя в программе на C# появился показанный выше паттерн придётся ну очень постараться.

WH>>Но если не отвлекаться от программирования, то в процессе работы над новой задачей со временем начинают появляться очень похожие куски кода.
WH>>Если язык позволяет, то они устраняются методами языка.
WH>>Язык с метапрограммированием может устранить что угодно.

I>Да, я выше показал пример — "App.Run()"
Ты показал, что ты любишь съезжать с темы, когда начинаешь понимать, что слил.

I>Макры ничем не лучше. Рано или поздно появляется паттерн который никуда не всунуть.
Обосновать можешь?

I>Более того — с компилятором так же появляется паттерн, от которого не избавиться потому, что разрабы перестали развивать компилятор (хотя бы в одном из направлений).
С компилятором монолитных языков типа C# они гарантированно появляются в любом случае.

I>В DSL паттернов не меньше. Возьми DSL навроде SQL или RegExp — полно паттернов.
I>Более того, любой ДСЛ обладает таким свойством — например BNF имеет кучу паттернов.
А в них уже есть метапрограммирование?

WH>>К сожалению, в общем случае, это возможно только если есть метапрограммирование.
I>Особенно, если закрывать глаза на паттерны в библиотеке макров.
Нет там паттернов. От слова совсем.
Паттерн это повторяющейся с небольшими отличиями кусок кода.
В библиотеку макросов он уезжает в одном экземпляре.
И размножается уже компилятором во время компиляции программы.
Что там генерирует компилятор не важно.
Важно, что у нас в коде больше нет вот такой порнографии по всему коду.

push значение_1
push значение_2
call procedure

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

I>Не исчезла, а там где была там и осталась, только кода стало меньше. Зато теперь человек, который хочет понять этот код, должен неизвестно где рыться, что бы понять о чем речь. А если ему надо поменять стратегию инициализации, связывания и тд и тд, то и вовсе бедствие.
Бедствие будет если этот код размножить в 100 раз и пойти менять его руками.
А вот когда у тебя все генерируется то всё просто.
Буквально вчера мне понадобилось сделать то, о чем ты говоришь.
В том куске кода, который я не видел, наверное, год. И его ещё и хардкейс весьма основательно перекопал.
Заработало всё с первой попытки.

И подобные изменения происходят регулярно.

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

Я описываю реальную практику применения метапрограммирования.

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


И вот опять же как все плохо описано в книгах и статьях, из википедии только кусок смог найти полезный. Хотя особо больше нигде и не искал.
Суть данного паттерна описывается здесь: http://en.wikipedia.org/wiki/Factory_(object-oriented_programming)#Applicability
Вся статья посвящена самому паттерну, то как его использовать, какие плюсы он дает, но только вот то что по ссылке, эти три пункта реально объясняют зачем он нужен.
Выберите пункт и предложите другое решение, которое не является паттерном.

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

WH>Нет там паттернов. От слова совсем.
WH>Паттерн это повторяющейся с небольшими отличиями кусок кода.
WH>В библиотеку макросов он уезжает в одном экземпляре.
WH>И размножается уже компилятором во время компиляции программы.
WH>Что там генерирует компилятор не важно.
WH>Важно, что у нас в коде больше нет вот такой порнографии по всему коду.
WH>

WH>push значение_1
WH>push значение_2
WH>call procedure
WH>

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

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

A>Мы все же про разные паттерны. Мы тут про те паттерны, не которые повторяющиеся куски кода, а про те, которые идеологически являются эффективным способом некой проблемы.
A>Про повторяющися код вы правы, он хорошо решается кодогенерацией, метапрограммированием, в том числе аспектно ориентированное программирование про тоже самое, но в этой ветки мы говорим про другое.
Нет никакого идеологически эффективного способа.
Это выдумка авторов книжек по паттернам, ибо им нужно эти книги продавать.
Ибо если бы они назывались честно "как писать повторяющейся код" то их никто бы не стал покупать.

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

I>>Не исчезла, а там где была там и осталась, только кода стало меньше. Зато теперь человек, который хочет понять этот код, должен неизвестно где рыться, что бы понять о чем речь. А если ему надо поменять стратегию инициализации, связывания и тд и тд, то и вовсе бедствие.
WH>Бедствие будет если этот код размножить в 100 раз и пойти менять его руками.
WH>А вот когда у тебя все генерируется то всё просто.

Давай на секунду представим, что в код лезет человек, который читал не ту книгу по паттернам, и ему твоя AbstractFactory ни о чем не говорит.
Что он должен подумать про override(x, y) и тд ?

Паттерн или нет?

#define container_of(ptr, type, member) ({                      \
          const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
          (type *)( (char *)__mptr - offsetof(type,member) );})