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

I>Где тут паттерн — мне не ясно. Зато ясно, что WH считает такой говнокод паттерном.
Странно. А как раз мне — всё ясно. Это же паттерн assert, который приходится лепить вот в таком виде при отсутствии в языке понятия assert. В С++ такой копипейст традиционно реализуется при помощи макросов.

I>Буквально там нет такой фразы, но они везде упоминают например reusable, flexible design. Насколько я понимаю, копипаста не является ни reusable ни flexible.
Мне непонятен ваш ход мысли. Копипаста является reusable по определению, и flexible по факту.

I>Описания у фаулера и гоф не нужны для поиска и принятия решений, а паттерны — нужны. http://kolesnik.ru/2006/pattern/
Вы жонглируете понятиями. Давайте я приведу ссылку на понятие "паттерн" из вышивальной практики, и буду ссылаться на него при обсуждении свойств паттернов софтостроения.

S>>Волшебным образом оказывается, что 99.999% архитекторов прекрасно обходятся без этого паттерна ещё с пятидесятых годов. Эта наблюдаемая действительность полностью противоречит вашим утверждениям.
I>Именно этот паттерн не нужен в большинстве насущных задач.
Вы шутите? В моём опыте в 99.999999999% систем понятие "вызов подпрограммы" используется в полный рост и играет значительную роль в архитектуре.

I>"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."
И? Вам что, непонятно, что здесь сразу делается предположение о наличии объектов с изменяемым состоянием? И это несмотря на то, что в процитированном виде паттерн совершенно бесполезен, как и приведённый AVK "паттерн" Стратегия. Вместо решения опять имеем задачу. Вот нам нужно сделать так, чтобы состояние N объектов менялось в зависимости от изменения состояния одного объекта. Что имеем? Офигенное решение: "давайте зададим зависимость так, чтобы состояние N объектов менялось в зависимости от изменения состояния одного объекта.
Знаете, любой так может решать любые задачи. "Как сверстать бюджет РФ без дефицита?" — "Определите размер каждой расходной статьи бюджета так, чтобы их сумма не превышала сумму размеров доходных статей".
К счастью, в настоящих паттернах всё же приводят решение, а не только формулировку задачи.

I>Я про обучение. Дать человеку C# это совсем не тоже что обучить паттернам и ждать что он не будет изобретать велосипед. Я видел около десятка реализаций Observer на C# все до одной уникальные и все из них я заменил на обычный эвент. Последний раз в прошлом месяце кстати говоря.
I>Для того, что бы человек прекратил изобретать велосипеды Observer, нужно обязательно прокачать этот паттерн и показать, как он реализован хотя бы в C#.
А может быть, просто надо рассказать человеку про event?

Тогда в голове будет всего лишь нечто, чему соответсвует (с некоторой стпенью точности) "Observer:Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." и как только человек задетектил факт использования этого паттерна, результатом будет решение в подходящем виде в зависимости от контекста(ЯП и тд и тд).
Что вы называете "фактом использования паттерна"? Постановку задачи, или готовое решение?

I>Я уже говорил, паттерны позволяют искать решение не вдаваясь в детали.
Нет, не позволяют.

I>Сам код в деталях не важен.
Вы только что писали мне ровно противоположное. А как же windbg?

I>Нету шансов если ты не знаешь что такое блочный итератор как ты говоришь "в общих чертах", все что тебе нужно — это название паттерна который реализует этот yield. Всё. Если ты не знаешь этого или с этим паттерном работал мало, никогда и ни при каких условиях тебе не видать эффективного решения.
Этот поток сознания я не понял, простите.

I>Это никакой не изъян Как минимум со времен Ньютона известно, что к решению может приводить даже падение яблока на голову. Очевидно, у нас нет такой фичи, которая могла бы сказать, в каких направлениях надо копать что бы найти решение.
Тем не менее, учёные не занимаются ронянием на головы яблок, пытаясь уподобиться Ньютону. Вас это не удивляет?

I>Эффект с учетом затрат в условных единицах.
Что вы считаете эффектом? Что вы считаете затратами?

I>Я в курсе и потому не удивляюсь тому коду, что у таких разработчиков на выходе, а ты мне доказываешь, что они смогут вдруг изобрести какие то асинхронные паттерны. Так не бывает.
Ну я же изобрёл. При этом я никак не пользовался знанием того, какие именно объекты порождаются для хранения переменных, захваченных в блоке, и как там устроены переходы в стейт-машине.

I>Когда дебуггер выбросит тебя в нативный код и тебе нужно будет понять хотя бы приблизительно, что же там происходит, а может даже накидать пару строчек этого кода.
Какого кода? На ассемблере?
I>Есть некоторые сомнения, что исходники всех возможных нативных модулей входят в поставку windbg.
Ну то есть вы придумали изолированный пример, который встречается один-два раза в жизни, и то не всем.
И на основании этого вы вправду считаете, что нельзя допускать к разработке и проектированию людей, не владеющих ассемблером? Экстремальненько.

I>В обратную не работает. Инженеру очень важно понимаеть как что работает.
И какое отношение к этому имеют паттерны? Особенно в любимом вами виде "ни о чём"?

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

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

I>Вот хороший пример — http://rsdn.ru/forum/philosophy/4871897.1.aspx

Автор: icWasya
Дата: 28.08.12

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

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

Ф>Нет, просто желательно знать название и назначение этого паттерна и реализацию этого паттерна в языке.

Ф>Во-первых для того, чтобы уметь объяснить своё решение другому разработчику, возможно пишущему на другом ЯП, своё решение.
А, ну это, несомненно, важная штука. То есть опять же — самому разработчику это не нужно. Это нужно другому разработчику, который говорит на убогом языке, в котором нет реализации паттерна observer.

Ф>Во-вторых, для того, чтобы не изобретать велосипед(ы) и не писать Publisher-Subscriber вручную (очень это плюсисты и явисты это любят при переходе на C#).
Для этого важно знать не паттерн, а само наличие event. Конечно, плюсисты и явисты делают всё вручную. А ещё они не любят цикл foreach, просто потому, что у них for(int i=0; i< count; i++) набирается на одном дыхании вслепую за 0.6 секунды.

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

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

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

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

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

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

I>>Где тут паттерн — мне не ясно. Зато ясно, что WH считает такой говнокод паттерном.
S>Странно. А как раз мне — всё ясно. Это же паттерн assert, который приходится лепить вот в таком виде при отсутствии в языке понятия assert. В С++ такой копипейст традиционно реализуется при помощи макросов.

А что, Assert.IsTrue(a != b) уже рокет саенс и надо обяательно писать говнокод ?

I>>Буквально там нет такой фразы, но они везде упоминают например reusable, flexible design. Насколько я понимаю, копипаста не является ни reusable ни flexible.
S>Мне непонятен ваш ход мысли. Копипаста является reusable по определению, и flexible по факту.

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

I>>Описания у фаулера и гоф не нужны для поиска и принятия решений, а паттерны — нужны. http://kolesnik.ru/2006/pattern/
S>Вы жонглируете понятиями. Давайте я приведу ссылку на понятие "паттерн" из вышивальной практики, и буду ссылаться на него при обсуждении свойств паттернов софтостроения.

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

S>>>Волшебным образом оказывается, что 99.999% архитекторов прекрасно обходятся без этого паттерна ещё с пятидесятых годов. Эта наблюдаемая действительность полностью противоречит вашим утверждениям.
I>>Именно этот паттерн не нужен в большинстве насущных задач.
S>Вы шутите? В моём опыте в 99.999999999% систем понятие "вызов подпрограммы" используется в полный рост и играет значительную роль в архитектуре.

Цитирую себя: "функция в детстве была паттерном 'вызов подпрограммы'"
Реализация паттерна перекочевала в язык и с этого момента стала абстракцией, это естественный процесс, я повторяю это уже раз наверное пяццот.

I>>"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."
S>И? Вам что, непонятно, что здесь сразу делается предположение о наличии объектов с изменяемым состоянием? И

Здесь нет ничего про ЯП. Например нельзя сказать, C# это, С++ или Java или F#.

>это несмотря на то, что в процитированном виде паттерн совершенно бесполезен, как и приведённый AVK "паттерн" Стратегия. Вместо решения опять имеем задачу. Вот нам нужно сделать так, чтобы состояние N объектов менялось в зависимости от изменения состояния одного объекта. Что имеем? Офигенное решение: "давайте зададим зависимость так, чтобы состояние N объектов менялось в зависимости от изменения состояния одного объекта.
S>Знаете, любой так может решать любые задачи. "Как сверстать бюджет РФ без дефицита?" — "Определите размер каждой расходной статьи бюджета так, чтобы их сумма не превышала сумму размеров доходных статей".
S>К счастью, в настоящих паттернах всё же приводят решение, а не только формулировку задачи.

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

I>>Я про обучение. Дать человеку C# это совсем не тоже что обучить паттернам и ждать что он не будет изобретать велосипед. Я видел около десятка реализаций Observer на C# все до одной уникальные и все из них я заменил на обычный эвент. Последний раз в прошлом месяце кстати говоря.
I>>Для того, что бы человек прекратил изобретать велосипеды Observer, нужно обязательно прокачать этот паттерн и показать, как он реализован хотя бы в C#.
S>А может быть, просто надо рассказать человеку про event?

Я выбросил слишком много обсерверов в проектах на C# что бы поверить в магию "рассказать человеку про event".
Рассказать это слишком мало, нужно что бы человек прочувствовал event своими руками, а потом прочувствовал этими же руками разницу между event и самопальным Observer. А далее ему надо дать несколько задач что бы он сам свел их к обсерверу.
Вот так — работает !

S>Тогда в голове будет всего лишь нечто, чему соответсвует (с некоторой стпенью точности) "Observer:Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." и как только человек задетектил факт использования этого паттерна, результатом будет решение в подходящем виде в зависимости от контекста(ЯП и тд и тд).
S>Что вы называете "фактом использования паттерна"? Постановку задачи, или готовое решение?

Проблема + некоторое решение.

I>>Я уже говорил, паттерны позволяют искать решение не вдаваясь в детали.
S>Нет, не позволяют.

Я привел описание, покажи что в нем не так для той задачи что я упомянул: Слоистый коктейль -> справочник по плотности напитков -> список рецептов -> план работ/закупок.

I>>Сам код в деталях не важен.
S>Вы только что писали мне ровно противоположное. А как же windbg?

Это про конкретный паттерн — вызов подпрограммы и пример реализации для x86. Пример реализации естественно конкретный, с деталями.

I>>Нету шансов если ты не знаешь что такое блочный итератор как ты говоришь "в общих чертах", все что тебе нужно — это название паттерна который реализует этот yield. Всё. Если ты не знаешь этого или с этим паттерном работал мало, никогда и ни при каких условиях тебе не видать эффективного решения.
S>Этот поток сознания я не понял, простите.

Бывает.

I>>Это никакой не изъян Как минимум со времен Ньютона известно, что к решению может приводить даже падение яблока на голову. Очевидно, у нас нет такой фичи, которая могла бы сказать, в каких направлениях надо копать что бы найти решение.
S>Тем не менее, учёные не занимаются ронянием на головы яблок, пытаясь уподобиться Ньютону. Вас это не удивляет?

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

I>>Эффект с учетом затрат в условных единицах.
S>Что вы считаете эффектом? Что вы считаете затратами?

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

I>>Я в курсе и потому не удивляюсь тому коду, что у таких разработчиков на выходе, а ты мне доказываешь, что они смогут вдруг изобрести какие то асинхронные паттерны. Так не бывает.
S>Ну я же изобрёл. При этом я никак не пользовался знанием того, какие именно объекты порождаются для хранения переменных, захваченных в блоке, и как там устроены переходы в стейт-машине.

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

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

Вопрос в том, как разработчик не имея твоего багажа выдать точно такое же решение. У тебя есть ответ ?

I>>Когда дебуггер выбросит тебя в нативный код и тебе нужно будет понять хотя бы приблизительно, что же там происходит, а может даже накидать пару строчек этого кода.
S>Какого кода? На ассемблере?

Да.

I>>Есть некоторые сомнения, что исходники всех возможных нативных модулей входят в поставку windbg.
S>Ну то есть вы придумали изолированный пример, который встречается один-два раза в жизни, и то не всем.
S>И на основании этого вы вправду считаете, что нельзя допускать к разработке и проектированию людей, не владеющих ассемблером? Экстремальненько.

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

I>>В обратную не работает. Инженеру очень важно понимаеть как что работает.
S>И какое отношение к этому имеют паттерны? Особенно в любимом вами виде "ни о чём"?

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

см про слоистый коктейль и блочные итераторы.

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

I>>Вот представь, ты пишешь легальынй код, практически как в мануале на который ты дал ссылку, только внезапно функция у тебя локальная...
S>Ну, вот на практике у меня ни разу не возникло локальной функции.
S>Сейчас вот разгребаю код чужого проекта. Там локальных функций — горы. Но они нигде не передаются по ссылке. В принципе не используется этот приём.

Значит код старый. Как выяснилось, даже вниз передавать эти локальные функции было сильно сложно

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

Ф>>Во-вторых, для того, чтобы не изобретать велосипед(ы) и не писать Publisher-Subscriber вручную (очень это плюсисты и явисты это любят при переходе на C#).
S>Для этого важно знать не паттерн, а само наличие event. Конечно, плюсисты и явисты делают всё вручную. А ещё они не любят цикл foreach, просто потому, что у них for(int i=0; i< count; i++) набирается на одном дыхании вслепую за 0.6 секунды.

Это четко доказывает что само знание о наличии event как минимум недостаточно.

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

I>Цитирую себя: "функция в детстве была паттерном 'вызов подпрограммы'"
I>Реализация паттерна перекочевала в язык и с этого момента стала абстракцией, это естественный процесс, я повторяю это уже раз наверное пяццот.
После чего перестала быть паттерном.
О чем я тебе с самого начала и говорил.

Теперь осталось только понять, что любой паттерн можно засунуть в язык.

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

I>>Цитирую себя: "функция в детстве была паттерном 'вызов подпрограммы'"
I>>Реализация паттерна перекочевала в язык и с этого момента стала абстракцией, это естественный процесс, я повторяю это уже раз наверное пяццот.
WH>После чего перестала быть паттерном.

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

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

I>А что, Assert.IsTrue(a != b) уже рокет саенс и надо обяательно писать говнокод ?
Нет, не обязательно. Но когда мы видим многократно повторённый код, приведённый WH, мы прозреваем наличие паттерна, даже если его никто заранее не описал.

I>на счет reusable я погорячился
I>flexible — возможность легко и быстро привести код в соответствие изменяющимся требованиям.
Это вы, имхо, только что сами придумали. У банды про вот это как раз ничего нет. Потому что их паттерны никак не позволяют "легко и быстро привести код в соответствие изменяющимся требованиям". Там скорее про то, что можно "согнуть под конкретное место использования".

I>Проверяем твое высказывани — копипастим код под конкретный набор требований и меняем требования.
I>Если копипаста flexible, то не составит труда внести изменения.
Ну, давайте пример изменения требований. И посмотрим, каков труд в случае "копипасты", и каков — в случае "ГоФ".

I>Я с самого начала говорю о том, откуда берутся паттерны и почему они актуальны. Практически все что сказано в этой статье при паттерны, применимо к паттернам из GoF. Вероятно ты понимаешь паттерн именно как фиксированое описание
Я уже привёл своё определение паттерна. Вы внезапно присылаете ссылку на "паттерны мышления", которая про совершенно другие вещи с похожим названием. Понимаете? Из того, что баран и овца похожи, никак не следует похожесть баранки и овчарки. Такое жонглирование терминами вас никуда не приведёт.
I>Реализация паттерна перекочевала в язык и с этого момента стала абстракцией, это естественный процесс, я повторяю это уже раз наверное пяццот.
Вы это не повторяете, а пытаетесь спорить ровно с этим утверждением. Это мы с WH утверждаем, что паттерны должны перекочевать в язык и стать абстракцией, и с этого момента сами паттерны нафиг не нужны в 99.99999% случаев. А вы притягиваете за уши любые аргументы, лишь бы с этим поспорить.

I>Здесь нет ничего про ЯП. Например нельзя сказать, C# это, С++ или Java или F#.
Здесь очень много про ЯП. Можно сказать, что это точно не дотнет (т.к. этот паттерн в дотнете нахрен не упал, при наличии готовой абстракции), и точно не SQL (потому что там нет объектов), и точно не чистый функциональный язык, т.к. там нет изменяемого состояния.
Итого, остаётся С++ либо Джава — что интуитивно было понятно с самого начала, т.к. именно под них и затачивала свои паттерны Банда. И стыдливые попытки спрятать этот факт за туманностью формулировок не помогают.

I>Я привел основную часть и этого достаточно что бы найти решение, потому что паттерн сам по себе решением не является и являться не может.
Да ладно. Может вы всё же посмотрите определение термина Паттерн — хотя бы в wiki?

I>Я выбросил слишком много обсерверов в проектах на C# что бы поверить в магию "рассказать человеку про event".
I>Рассказать это слишком мало, нужно что бы человек прочувствовал event своими руками, а потом прочувствовал этими же руками разницу между event и самопальным Observer. А далее ему надо дать несколько задач что бы он сам свел их к обсерверу.
Судя по вашему описанию, эти люди не знали про event, зато знали паттерн Observer. Что служит аргументом в пользу меня — то есть того, что учить паттернам вреднее, чем учить языку.
Точно так же я могу ожидать того, что дельфист-новичок, начитавшись ГоФ, может броситься писать классы фабрик, вместо того, чтобы изучить TClass и виртуальные конструкторы.

S>>Тогда в голове будет всего лишь нечто, чему соответсвует (с некоторой стпенью точности) "Observer:Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." и как только человек задетектил факт использования этого паттерна, результатом будет решение в подходящем виде в зависимости от контекста(ЯП и тд и тд).
S>>Что вы называете "фактом использования паттерна"? Постановку задачи, или готовое решение?
I>Проблема + некоторое решение.
Ок. Вы предлагаете переходить к решению от "Проблема + некоторое решение"? Зачем, если решение уже есть?

I>Я привел описание, покажи что в нем не так для той задачи что я упомянул: Слоистый коктейль -> справочник по плотности напитков -> список рецептов -> план работ/закупок.
То, что вы решили задачу крайне неэффективно. Для сформулированной вами задачи достаточно нагуглить рецепт коктейля Б-52, или мохито, или ещё чего-то конкретного. А ваше "решение" (в котором решения-то и нету — где коктейль??? У вас пока что только план по построению плана) запросто может привести к коктейлю из растительного масла и кока-колы, которым можно удивить только в неприятном смысле.

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

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

I>Эффект — решение проблемы. Затраты — время на реализацию, майнтенанс и суппорт помножить на ЗП.
А, то есть вас интересуют затраты на стороне программиста. Уже хорошо (странно, что вы так долго сопротивлялись попыткам это выяснить), а то в этом форуме некоторые считают "затратами" косвенность вызовов.
Отлично. Для этих затрат есть вполне приличные эмпирические метрики. Эффекты первого порядка — это просто размер кода.
Поэтому подпрограмма всегда лучше, чем копи-пейст.
Эффекты второго порядка — контроль компилятора. Поэтому нативно поддержанная абстракция всегда лучше, чем подпрограмма с неизвестной компилятору семантикой.
Скажем, в случае "говнокода" про ассерт, компилятор может нас предупредить про unreachable code, если мы заведомо нарушаем условие ассерта. То же самое можно сделать в случае нативной абстракции assert. В случае Assert.IsTrue() компилятор нам ничем не поможет — он понятия не имеет о том, что в случае вычисления аргумента в false будет брошено исключение и весь следующий код пойдёт лесом.

I>Ну вобще не ясно, как проверить какой набор знаний об этих итератора у тебя уже был заранее.
Придётся поверить мне на слово.

I>Вообще, зачем знать эти детали ? Паттерн избавляет тебя от этого. Если ты задетектил паттерн как ДКА, то и решение будет искаться именно с учетом ДКА. А если вдруг тебе пришло в голову короутина, то и решение будет искаться именно таким образом.
Я не понимаю этот набор слов. Я ничего не задетектил. Я просто заметил, что yield return превращает "энергичный" императивный код в "ленивый", позволяя вернуться к исполнению нашего императивного кода тогда, когда мы будем к этому готовы. Мне всё равно — ДКА там или демон Максвелла.
Просто есть удобная абстракция, с известными (из документации) наблюдаемыми свойствами.

I>Можно обойтись и без заглядывания непосредтсвенно в код, например если есть лет десять опыта и ты уже в курсе короутин, автоматов и прочих вещей, то из одного описания в мсдн + пару собственных попыток можно построить адекватную модель.
Мне не надо строить адекватную модель. Мне надо хорошо понимать, что за поведение у yield return. Многократные перечитывания GoF и Фаулера этому никак не помогут.

I>Вопрос в том, как разработчик не имея твоего багажа выдать точно такое же решение. У тебя есть ответ ?
Есть — учите матчасть. Под матчастью я понимаю знание того, как и для чего надо применять используемые инструменты.

I>Нельзя допускать к разработке людей, которые не понимают как работает виртуальная машина — так будет правильно. Для этого в университетах, что характерно даже в Мит и Стенфорде, студентов обучают довольно низкоуровневым вещам.
Какая виртуальная машина? Windbg не показывает виртуальных машин. Он показывает конкретный целевой код.
Нет, я не против того, чтобы это знать. Я вообще обоими руками за профайлеры и отладчики — но я не верю, что нужно всю жизнь готовиться к такому случаю.

S>>Простите, я не понимаю. Можно какой-то пример того, как я перебираю решения при помощи "паттернов"?
I>см про слоистый коктейль и блочные итераторы.
Оба примера говорят в мою пользу. См. выше.

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

I>Это четко доказывает что само знание о наличии event как минимум недостаточно.
Это понятно. Но это также доказывает, что самого знания о наличии Observer Pattern тоже недостаточно.
И из очевидных соображений мы понимаем, что знания о наличии event как минимум необходимо для того, чтобы им пользоваться.
Знания Observer Pattern необходимыми тут никак не являются.

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

I>>Это четко доказывает что само знание о наличии event как минимум недостаточно.
S>Это понятно. Но это также доказывает, что самого знания о наличии Observer Pattern тоже недостаточно.
S>И из очевидных соображений мы понимаем, что знания о наличии event как минимум необходимо для того, чтобы им пользоваться.
S>Знания Observer Pattern необходимыми тут никак не являются.

Как минимум event включает в себя observer

Вот пример:

public void Update(OperationArgs args)
{
  foreach(var c in clients)
  {
    c.ProcessOperation(new Operation(args));
  }
}

На этом этапе можно задетектить и проверить сам обсервер, и далее предложить конкретную реализацию, например с помощью event

event OperationStatusHandler ProgressChanged;
...
ProgressChanged(this, new OperationStatusArgs());
...
publisher.ProgressChanged += (s,a) => { ... };

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

I>>А что, Assert.IsTrue(a != b) уже рокет саенс и надо обяательно писать говнокод ?
S>Нет, не обязательно. Но когда мы видим многократно повторённый код, приведённый WH, мы прозреваем наличие паттерна, даже если его никто заранее не описал.

А если любой другой код многократно повторён ?

I>>на счет reusable я погорячился
I>>flexible — возможность легко и быстро привести код в соответствие изменяющимся требованиям.
S>Это вы, имхо, только что сами придумали. У банды про вот это как раз ничего нет. Потому что их паттерны никак не позволяют "легко и быстро привести код в соответствие изменяющимся требованиям". Там скорее про то, что можно "согнуть под конкретное место использования".

Изменения разумеется не любые а то и разговору не было.

I>>Проверяем твое высказывани — копипастим код под конкретный набор требований и меняем требования.
I>>Если копипаста flexible, то не составит труда внести изменения.
S>Ну, давайте пример изменения требований. И посмотрим, каков труд в случае "копипасты", и каков — в случае "ГоФ".

Мне это пока сложновато, осталось два дня до отпуска, так что извини.

I>>Я с самого начала говорю о том, откуда берутся паттерны и почему они актуальны. Практически все что сказано в этой статье при паттерны, применимо к паттернам из GoF. Вероятно ты понимаешь паттерн именно как фиксированое описание
S>Я уже привёл своё определение паттерна. Вы внезапно присылаете ссылку на "паттерны мышления", которая про совершенно другие вещи с похожим названием. Понимаете?

Я с самого начала говорил и говорю именно про это. Вещи эти никакие не другие, это вобщем одно и то же.

I>>Реализация паттерна перекочевала в язык и с этого момента стала абстракцией, это естественный процесс, я повторяю это уже раз наверное пяццот.
S>Вы это не повторяете, а пытаетесь спорить ровно с этим утверждением. Это мы с WH утверждаем, что паттерны должны перекочевать в язык и стать абстракцией, и с этого момента сами паттерны нафиг не нужны в 99.99999% случаев. А вы притягиваете за уши любые аргументы, лишь бы с этим поспорить.

Не паттерны, а их реализация. Ну реализовали скажем обсервер в языке. Что, автоматически все рукописные реализации исчезнут ? Это как минимум.

I>>Здесь нет ничего про ЯП. Например нельзя сказать, C# это, С++ или Java или F#.
S>Здесь очень много про ЯП. Можно сказать, что это точно не дотнет (т.к. этот паттерн в дотнете нахрен не упал, при наличии готовой абстракции), и точно не SQL (потому что там нет объектов), и точно не чистый функциональный язык, т.к. там нет изменяемого состояния.

Готовая абстракция не означает, что и все код будет ей соответствовать.

S>Итого, остаётся С++ либо Джава — что интуитивно было понятно с самого начала, т.к. именно под них и затачивала свои паттерны Банда. И стыдливые попытки спрятать этот факт за туманностью формулировок не помогают.

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

I>>Я привел основную часть и этого достаточно что бы найти решение, потому что паттерн сам по себе решением не является и являться не может.
S>Да ладно. Может вы всё же посмотрите определение термина Паттерн — хотя бы в wiki?

Решение с моей т.з. = код или подробная модель которую можно перевести в код. Обсервер например это ни то ни другое. И стратегия, и фабрика и тд и тд и тд. Вот конкретный UML для обсервера уже может считаться решением, но это, внезапно, не паттерн а уже реализация паттерна.

I>>Я выбросил слишком много обсерверов в проектах на C# что бы поверить в магию "рассказать человеку про event".
I>>Рассказать это слишком мало, нужно что бы человек прочувствовал event своими руками, а потом прочувствовал этими же руками разницу между event и самопальным Observer. А далее ему надо дать несколько задач что бы он сам свел их к обсерверу.
S>Судя по вашему описанию, эти люди не знали про event, зато знали паттерн Observer. Что служит аргументом в пользу меня — то есть того, что учить паттернам вреднее, чем учить языку.

Знали примерно так — вон форма, а у ней событие OnClick.

S>Точно так же я могу ожидать того, что дельфист-новичок, начитавшись ГоФ, может броситься писать классы фабрик, вместо того, чтобы изучить TClass и виртуальные конструкторы.

Так и будет.

S>>>Что вы называете "фактом использования паттерна"? Постановку задачи, или готовое решение?
I>>Проблема + некоторое решение.
S>Ок. Вы предлагаете переходить к решению от "Проблема + некоторое решение"? Зачем, если решение уже есть?

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

I>>Я привел описание, покажи что в нем не так для той задачи что я упомянул: Слоистый коктейль -> справочник по плотности напитков -> список рецептов -> план работ/закупок.
S>То, что вы решили задачу крайне неэффективно. Для сформулированной вами задачи достаточно нагуглить рецепт коктейля Б-52, или мохито, или ещё чего-то конкретного. А ваше "решение" (в котором решения-то и нету — где коктейль??? У вас пока что только план по построению плана) запросто может привести к коктейлю из растительного масла и кока-колы, которым можно удивить только в неприятном смысле.

Цитирую себя " Предположим, например, ты хочешь удивить друзей разными рецептами кровавой мери, но сам ты не бармен и тебе нужен список вариантов + список ингредиентов и тд. "
Как видишь, твое решение Б-52 или мохито мягко говоря задаче не удовлетворяет, а в моём случае маслу и коле просто неоткуда взяться
Все даже проще — "кровавая мери" уже можно рассматривать как паттерн, в котором основной ингредиент это томатный сок.

I>>Факт что этот вырожденый случай вполне вписывается в мою теорию В жизни почти любого программиста который подходил к задаче творчески, можно найти пример вроде яблока Ньютона. При чем, что характерно, в самых критических и сложных случаях именно так и случается.
S>И? Каким образом из этого вытекает необходимость учить именно паттерны, а не фен-шуй?

Ты сказал для начала "Надо понимать, что именно делает данный инструмент, вот и всё.". Я же объясняю, что этого недостаточно. Нету предела этому самому пониманию. Почему и как именно мозг заимствует модели откуда угодно — не ясно, но это факт.
Почему нужно учить паттерны — эти самые паттерны предшествуют абстракциям/понятиям. Нет хороших абстракций, вводи их. Не можешь — учи паттерны. Пример Эрика Мейера и linq с Rx показывает, что абстракции вроде простые, а почему то понадобилось ажно 15 лет что бы найти внятное решение.

S>Эффекты второго порядка — контроль компилятора. Поэтому нативно поддержанная абстракция всегда лучше, чем подпрограмма с неизвестной компилятору семантикой.
S>Скажем, в случае "говнокода" про ассерт, компилятор может нас предупредить про unreachable code, если мы заведомо нарушаем условие ассерта. То же самое можно сделать в случае нативной абстракции assert. В случае Assert.IsTrue() компилятор нам ничем не поможет — он понятия не имеет о том, что в случае вычисления аргумента в false будет брошено исключение и весь следующий код пойдёт лесом.

Это объясняет, почему реализации паттернов сначала уходят в инфраструктуру, а потом — в язык. Разве я с этим спорю ?

I>>Ну вобще не ясно, как проверить какой набор знаний об этих итератора у тебя уже был заранее.
S>Придётся поверить мне на слово.

Пудозреваю минимум лет десять программирования ?

I>>Вообще, зачем знать эти детали ? Паттерн избавляет тебя от этого. Если ты задетектил паттерн как ДКА, то и решение будет искаться именно с учетом ДКА. А если вдруг тебе пришло в голову короутина, то и решение будет искаться именно таким образом.
S>Я не понимаю этот набор слов. Я ничего не задетектил. Я просто заметил, что yield return превращает "энергичный" императивный код в "ленивый", позволяя вернуться к исполнению нашего императивного кода тогда, когда мы будем к этому готовы. Мне всё равно — ДКА там или демон Максвелла.

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

S>Просто есть удобная абстракция, с известными (из документации) наблюдаемыми свойствами.

Прежде чем использовать эту абстракцию, пудозреваю ты накидал возможно не одну кучу кода в APM, так или нет ?

I>>Можно обойтись и без заглядывания непосредтсвенно в код, например если есть лет десять опыта и ты уже в курсе короутин, автоматов и прочих вещей, то из одного описания в мсдн + пару собственных попыток можно построить адекватную модель.
S>Мне не надо строить адекватную модель. Мне надо хорошо понимать, что за поведение у yield return. Многократные перечитывания GoF и Фаулера этому никак не помогут.

А в чем разница между "строить адекватную модель" и "хорошо понимать что за поведение у yield return" ? По моему наличие понимания == наличие адекватной модели.

I>>Вопрос в том, как разработчик не имея твоего багажа выдать точно такое же решение. У тебя есть ответ ?
S>Есть — учите матчасть. Под матчастью я понимаю знание того, как и для чего надо применять используемые инструменты.

То есть, в конечном итоге нужно будет выяснить, что же представляет собой блочный итератор

I>>Нельзя допускать к разработке людей, которые не понимают как работает виртуальная машина — так будет правильно. Для этого в университетах, что характерно даже в Мит и Стенфорде, студентов обучают довольно низкоуровневым вещам.
S>Какая виртуальная машина? Windbg не показывает виртуальных машин. Он показывает конкретный целевой код.
S>Нет, я не против того, чтобы это знать. Я вообще обоими руками за профайлеры и отладчики — но я не верю, что нужно всю жизнь готовиться к такому случаю.

Разве я говорю что надо всю жизнь готовиться к такому ? Вполне достаточно освоить азы низкоуровневого программирования что бы худо-бедно сориентировать буде какой случай возникнет.

S>>>Простите, я не понимаю. Можно какой-то пример того, как я перебираю решения при помощи "паттернов"?
I>>см про слоистый коктейль и блочные итераторы.
S>Оба примера говорят в мою пользу. См. выше.

Совсем неочевидно с учетом примеров про Б-52 или мохито в качестве вариантов кровавой мери

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

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

I>Изменения разумеется не любые а то и разговору не было.
Ну вот видите.
I>Мне это пока сложновато, осталось два дня до отпуска, так что извини.
Не переживайте. После отпуска вам это тоже будет сложновато, т.к. паттерны и есть копипаста. Другого варианта нет.

I>Я с самого начала говорил и говорю именно про это. Вещи эти никакие не другие, это вобщем одно и то же.
На этом можно было бы закончить, т.к. вы выбрали какую-то неортодоксальную трактовку термина.
Никто в топике не утверждал, что паттерны мышления — копипаста. Это, очевидно, ложное утверждение.
А вот паттерны софтостроения (то, чем занимался Фаулер и ГоФ) — копипаста.
Уже одного этого достаточно, чтобы понять, что "одним и тем же" эти два вида паттернов являться никак не могут.

I>Не паттерны, а их реализация. Ну реализовали скажем обсервер в языке. Что, автоматически все рукописные реализации исчезнут ? Это как минимум.
Реализации — не исчезнут. Исчезнет потребность в них.

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

I>Возьми пролог и напиши аналог микрософт офиса со всеми приблудами, ну, хотя бы приблизительно. Внезапно, тебе потребуются все эти паттерны. А язык — пролог.
Не смешите меня так сильно, сегодня ещё не пятница. Может, вы попробуете привести пример реализации хотя бы одного паттерна — скажем, Bridge, на языке Пролог?

I>Решение с моей т.з. = код или подробная модель которую можно перевести в код. Обсервер например это ни то ни другое.
С чего бы это? Observer даёт подробные инструкции о том, как и что переводить в код.
И стратегия, и фабрика и тд и тд и тд. Вот конкретный UML для обсервера уже может считаться решением, но это, внезапно, не паттерн а уже реализация паттерна.
Это не реализация паттерна, а неотъемлемая часть паттерна — его решение.

I>Знали примерно так — вон форма, а у ней событие OnClick.
Вы подтверждаете мои подозрения.

I>Так и будет.
Ну так надо учить людей абстракциям, а не паттернам.

I>Цитирую себя " Предположим, например, ты хочешь удивить друзей разными рецептами кровавой мери, но сам ты не бармен и тебе нужен список вариантов + список ингредиентов и тд. "
I>Как видишь, твое решение Б-52 или мохито мягко говоря задаче не удовлетворяет, а в моём случае маслу и коле просто неоткуда взяться
Как неоткуда? Из справочника плотностей напитков. Вы же не думаете, что в нём будет только джин, водка, томатный сок, и соус табаско.
I>Все даже проще — "кровавая мери" уже можно рассматривать как паттерн, в котором основной ингредиент это томатный сок.
Всё гораздо хуже. Без знаний о том, как именно наливать напитки, вы даже из правильных ингредиентов получите мерзкую смесь.

I>Почему нужно учить паттерны — эти самые паттерны предшествуют абстракциям/понятиям. Нет хороших абстракций, вводи их. Не можешь — учи паттерны. Пример Эрика Мейера и linq с Rx показывает, что абстракции вроде простые, а почему то понадобилось ажно 15 лет что бы найти внятное решение.
Абстракции — сложные.

I>Это объясняет, почему реализации паттернов сначала уходят в инфраструктуру, а потом — в язык. Разве я с этим спорю ?
Да, не знаю зачем.

I>Пудозреваю минимум лет десять программирования ?
Двадцать.

I>Прежде чем использовать эту абстракцию, пудозреваю ты накидал возможно не одну кучу кода в APM, так или нет ?
Нет.

S>>Мне не надо строить адекватную модель. Мне надо хорошо понимать, что за поведение у yield return. Многократные перечитывания GoF и Фаулера этому никак не помогут.

I>А в чем разница между "строить адекватную модель" и "хорошо понимать что за поведение у yield return" ? По моему наличие понимания == наличие адекватной модели.
Ок, если в ваше понимание адекватной модели входит только наблюдаемое поведение — тогда мы говорим об одном и том же. Но подробности реализации (те самые, которые указывают в паттерне) тут не нужны.

I>То есть, в конечном итоге нужно будет выяснить, что же представляет собой блочный итератор
Нет. Нужно выяснить, что он делает.

I>Разве я говорю что надо всю жизнь готовиться к такому ? Вполне достаточно освоить азы низкоуровневого программирования что бы худо-бедно сориентировать буде какой случай возникнет.
Паттернов — много. Не все из них сводятся к вызову функции в stdcall.

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

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

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

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

Ни в коем случае.

I>>Изменения разумеется не любые а то и разговору не было.
S>Ну вот видите.
I>>Мне это пока сложновато, осталось два дня до отпуска, так что извини.
S>Не переживайте. После отпуска вам это тоже будет сложновато, т.к. паттерны и есть копипаста. Другого варианта нет.

Если подходить со стороны "это всё равно копипаста" то с таким же успехом можно любой код назвать копипастой

I>>Не паттерны, а их реализация. Ну реализовали скажем обсервер в языке. Что, автоматически все рукописные реализации исчезнут ? Это как минимум.
S>Реализации — не исчезнут. Исчезнет потребность в них.

Совсем необязательно. Есть например всевозможные оптимизации, есть случаи с несколькими языками. Например в C# встроены итераторы. Открываем класс Enumerable и видим, что наравне с православными итераторами, если реализации паттерна в чистом виде. Опаньки !

И второй момент — объясни, чем обсервер отличается от эвента. Например, что если есть некоторый язык, в котором есть та же фича, но называется как нибудь иначе, например — сигнал. Как с этим быть ?

I>>Готовая абстракция не означает, что и все код будет ей соответствовать.
S>Вы опять спорите с утверждением, которого никто не делал. Зачем?

Я показываю что цифра 99.99999% взята с потолка и не соответсвует действительности.

I>>Возьми пролог и напиши аналог микрософт офиса со всеми приблудами, ну, хотя бы приблизительно. Внезапно, тебе потребуются все эти паттерны. А язык — пролог.
S>Не смешите меня так сильно, сегодня ещё не пятница. Может, вы попробуете привести пример реализации хотя бы одного паттерна — скажем, Bridge, на языке Пролог?

Что бы реализовать такой софт придется всунуть в пролог например весь православный ООП.

I>>Решение с моей т.з. = код или подробная модель которую можно перевести в код. Обсервер например это ни то ни другое.
S>С чего бы это? Observer даёт подробные инструкции о том, как и что переводить в код.

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

S>И стратегия, и фабрика и тд и тд и тд. Вот конкретный UML для обсервера уже может считаться решением, но это, внезапно, не паттерн а уже реализация паттерна.
S>Это не реализация паттерна, а неотъемлемая часть паттерна — его решение.

"решение" является частью паттерна, только решение не то, что нам надо, а скорее "мета-решение".

I>>Цитирую себя " Предположим, например, ты хочешь удивить друзей разными рецептами кровавой мери, но сам ты не бармен и тебе нужен список вариантов + список ингредиентов и тд. "
I>>Как видишь, твое решение Б-52 или мохито мягко говоря задаче не удовлетворяет, а в моём случае маслу и коле просто неоткуда взяться
S>Как неоткуда? Из справочника плотностей напитков. Вы же не думаете, что в нём будет только джин, водка, томатный сок, и соус табаско.

В данном случае я могу спокойно опираться на свой предыдущий опыт или отфильтровать сомнительные коктейли на стадии приготовления. Паттерны это не запрещают.

I>>Все даже проще — "кровавая мери" уже можно рассматривать как паттерн, в котором основной ингредиент это томатный сок.
S>Всё гораздо хуже. Без знаний о том, как именно наливать напитки, вы даже из правильных ингредиентов получите мерзкую смесь.

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

I>>Почему нужно учить паттерны — эти самые паттерны предшествуют абстракциям/понятиям. Нет хороших абстракций, вводи их. Не можешь — учи паттерны. Пример Эрика Мейера и linq с Rx показывает, что абстракции вроде простые, а почему то понадобилось ажно 15 лет что бы найти внятное решение.
S>Абстракции — сложные.

Значи всё еще хуже. Можно смело ожидать что большинство программистов их просто не поднимет в требуемый срок. WH например ратует за избавление индустрии от всех таких программистов

I>>Это объясняет, почему реализации паттернов сначала уходят в инфраструктуру, а потом — в язык. Разве я с этим спорю ?
S>Да, не знаю зачем.

Я уже раз пятьсот сказал, что такое движение это естественный процесс. Стало быть если я счем то спорю, то явно не с этим

I>>Пудозреваю минимум лет десять программирования ?
S>Двадцать.

То есть, твой случай можно спокойно скипнуть.

I>>Прежде чем использовать эту абстракцию, пудозреваю ты накидал возможно не одну кучу кода в APM, так или нет ?
S>Нет.

А что ты делал двадцать лет ? Писал примитивный императивный код и даже не пробовал ни асихронное программирование, ни функциональное, ни ООП?

I>>То есть, в конечном итоге нужно будет выяснить, что же представляет собой блочный итератор
S>Нет. Нужно выяснить, что он делает.

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

I>>Разве я говорю что надо всю жизнь готовиться к такому ? Вполне достаточно освоить азы низкоуровневого программирования что бы худо-бедно сориентировать буде какой случай возникнет.
S>Паттернов — много. Не все из них сводятся к вызову функции в stdcall.

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

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

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

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

Как называется эта абстракция и как быть если он реализована в другом языке иначе и называется иначе ?

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

I>Если подходить со стороны "это всё равно копипаста" то с таким же успехом можно любой код назвать копипастой
Нет, не любой.

I>Совсем необязательно. Есть например всевозможные оптимизации, есть случаи с несколькими языками. Например в C# встроены итераторы. Открываем класс Enumerable и видим, что наравне с православными итераторами, если реализации паттерна в чистом виде. Опаньки !
Что вы называете "реализацией паттерна в чистом виде"?

I>И второй момент — объясни, чем обсервер отличается от эвента. Например, что если есть некоторый язык, в котором есть та же фича, но называется как нибудь иначе, например — сигнал. Как с этим быть ?
Проектировать архитектуру в терминах сигналов.
Фича же может быть реализована по-разному. Скажем, в Delphi "евенты", которые были просто свойствами процедурного типа, не поддерживали множественность подписчиков. Это сильно повлияло на архитектуру DataSet и DataSource, которая занимает центральное место во всей VCL.
То есть поверх языковых средств был реализован отдельный паттерн для развязки подписчиков и публишеров. В C# нужды в этом паттерне нет, т.к. множественные подписчики работают из коробки.

I>Что бы реализовать такой софт придется всунуть в пролог например весь православный ООП.
Не торопитесь с примером — я схожу за попкорном.

I>То есть, это один из вариантов получения решения а не само решение, посколько Обсервер ничего не говорит про то, каким должен быть этот код.
И тем не менее, это очень конкретный вариант получения решения. Он содержит не только постановку задачи.

I>"решение" является частью паттерна, только решение не то, что нам надо, а скорее "мета-решение".
Конечно же это "мета-решение". Потому что "решение", которое нужно — это готовый код.
Когда у нас есть готовый код, мы не называем это "паттерном". Мы называем это "библиотекой", и даём её скачать бесплатно либо за деньги.
Посмотрите на то, как реализуется INotifyPropertyChanged — чистой воды копипаста. Поэтому решения — нет. Есть "мета решение" — "вызывайте PropertyChanged() из каждого сеттера". То есть мы знаем, как решить задачу, но не можем выразить это языковыми средствами. Ок, в новом фреймворке немножечко сократили копипасту при помощи нового атрибута и магии компилятора. Тем не менее, она всё ещё осталась, и никаких средств по избавлению от неё нету.
Поэтому мы по-прежнему имеем паттерн, а не решение.
Решением был бы макрос Nemerle или аннотация Java, которые бы заставляли компилятор автоматически генерировать копипасту за нас.
Тогда бы "Notify Property Changed Pattern" был бы не нужен.

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

I>>>Все даже проще — "кровавая мери" уже можно рассматривать как паттерн, в котором основной ингредиент это томатный сок.
S>>Всё гораздо хуже. Без знаний о том, как именно наливать напитки, вы даже из правильных ингредиентов получите мерзкую смесь.

I>Это все указано прямо в том справочнике
Что именно указано в справочнике?

I>Значи всё еще хуже. Можно смело ожидать что большинство программистов их просто не поднимет в требуемый срок. WH например ратует за избавление индустрии от всех таких программистов
Нет. Он ратует за избавление индустрии от книг типа GoF. Вместо паттернов ентерпрайз приложений можно иметь RoR и профит.

I>А что ты делал двадцать лет ? Писал примитивный императивный код и даже не пробовал ни асихронное программирование, ни функциональное, ни ООП?
Конечно же я пробовал ООП. Но большую часть времени из этих 20 лет никаких yield return в природе не существовало.

I>Я немного сомневаюсь, что до того, как изобрести конкретную короутину, ты не написал ни одного итератора.
Своих реализаций IEnumerable? Не, ни разу не потребовалось. Всегда хватало штатных коллекций.
Зато как только появился iterator block, я сразу стал пользовать его направо и налево — скажем, для того, чтобы превратить обход дерева в обычный foreach. Потому что делать это стало легко и приятно:

public IEnumerable<T> IterateWithChildren()(
{
  yield return this;
  foreach(var item in this)
    yield return item;
}

В С# 1.0 даже мысли не возникало о том, чтобы такое сделать.

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


I>Как называется эта абстракция и как быть если он реализована в другом языке иначе и называется иначе ?
Абстракция называется "вызов метода", "вызов процедуры", или "вызов функции". Она присутствует в нативном виде во всех императивных языках, начиная примерно с шестидесятых. Как именно она реализована, обычно мало кого интересует. Скажем, в JS вызов методов "внутри" устроен сильно не так, как в С++, тем не менее это совершенно не мешает читать JS-ный код, и проектировать систему с использованием JS.