Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
26 "это"! Это то, что раздражает в том, что является переводом.
ясно, хотя и не до конца… совсем.
Сейчас я вообще всех удивлю следите за пальцами. Делегирование это передача полномочий, полномочия это кусочек потока управления и потока данных из исходного потока — тогда для функции делегат это callback. Собственно почти все можно отразить в процедурном стиле но мне почему то лень. Утверждать что Банда не права и предлагать детали реализации как рассововерные это конечно сильно с учётом того, что паттерн это дизайн идея отражаюжая функциональность концептуально.
+ уже просто за упоминание Self :)
JavaScript makes me want to flip the table and say “F*ck this sh*t”, but I can never be sure what “this” refers to.
Что-то я запутался. Если прототипное наследование в JS — пример правильной делегации, то что же тогда, с точки зрения паттернов, происходит в ES6 классах? С одной стороны, это то самое классовое наследование, от которого следует отказаться в пользу делегирования, а с другой — всего лишь синтаксический сахар над прототипным наследованием.
Извините, если у меня каша в голове — я правда запутался и буду признателен, если кто-то поможет поставить понятия на место 0_о
Извините, если у меня каша в голове — я правда запутался и буду признателен, если кто-то поможет поставить понятия на место 0_о
Если делегирование по-прежнему лучше наследования, но при этом делегирование — всего лишь передача полномочий прототипу, то какой вывод можно сделать из первого утверждения:
1) прототипное наследование лучше наследования классов?
2) делегирование невозможно без прототипного наследования?
Кажется автор вводит свою уникальную терминологию, которая не вяжется с терминологией «банды четырёх», либо я просто не смог понять посыл автора.
1) прототипное наследование лучше наследования классов?
2) делегирование невозможно без прототипного наследования?
Кажется автор вводит свою уникальную терминологию, которая не вяжется с терминологией «банды четырёх», либо я просто не смог понять посыл автора.
Название статьи весьма провокационное. Может трюк, чтобы продать концепцию и книжку заодно.
А по сути буквоедство и ограниченность мышления.
И при чем здесь GOF если термин делегирования используется повсеместно не так как понимал Либерман?
Можно дальше придираться к использованию терминов «интерфейс», «абстракция», «наследование» в программировании и пройтись по всем книжкам где они используются не так как считает автор и заодно порекламить книжку.
А по сути буквоедство и ограниченность мышления.
И при чем здесь GOF если термин делегирования используется повсеместно не так как понимал Либерман?
Можно дальше придираться к использованию терминов «интерфейс», «абстракция», «наследование» в программировании и пройтись по всем книжкам где они используются не так как считает автор и заодно порекламить книжку.
С чего вообще автор взял, что «делегирование» — это когда self сохраняется? Вы обратите внимание на раздел «Ну и назовём это как угодно» — он там даже не отвечает на свой же вопрос, а фактически говорит: «То, что я называю „делегирование“ в C++ отсутствует, значит это не делегирование».
Эээ. Что?
Эээ. Что?
Весело получается. Сначала говорится, что все уверены в одном и том же, но они не правы. А потом объясняется что шаблоны проектирования нужны для общения на одном языке.
Так все и общаются на одном языке, пусть даже и «неправильно» называют то о чем хотят сказать.
Если все договорятся называть машину тачкой, то ничего не изменится, все будут понимать друг друга.
А яваскриптовое поведение паттернами можно реализовать через Цепочку Обязанностей.
Так все и общаются на одном языке, пусть даже и «неправильно» называют то о чем хотят сказать.
Если все договорятся называть машину тачкой, то ничего не изменится, все будут понимать друг друга.
А яваскриптовое поведение паттернами можно реализовать через Цепочку Обязанностей.
Неоправданное сужение* значения общеизвестного и общеиспользуемого термина. И то, что не удалось выразить результат такого сужения в терминах C++ (и, видимо, и C#/Java), ясно об этом свидетельствует.
* Это в лучшем случае, потому что есть подозрение, что описываемый приём вообще делегированию ортогонален.
* Это в лучшем случае, потому что есть подозрение, что описываемый приём вообще делегированию ортогонален.
…Спустя почти 3 года после публикации русского перевода приходится констатировать, что народ так и не понял, о чем статья :D
Я вообще не понял претензий автора. GoF, давая определения, могли назвать делегированием всё что угодно, в частности то, что происходит в декораторе. А то что автор статьи хочет называть делегированием, GoF назвали цепочкой обязанностей.
Вы, судя по всему, не первый и, подозреваю, не последний :)
…Претензии автора максимально четко описаны в третьем абзаце:
Далее по тексту все «разжевано»:
Во-первых, к моменту публикации GoF термин «делегирование» уже был «занят» — дана ссылка на статью, где смысл термина подробно расписан. В науке принято использовать уже «занятые» термины в соответствии с той смысловой нагрузкой, которую в них вложил автор термина. В GoF, если посмотреть на пример c Окном и Прямоугольником, паттерн «делегирование» имеет смысл, отличный от вложенного в этот термин в статье 1986 года.
Но это лишь полбеды — в конце концов, GoF на порядки более известен, чем та статья, так что можно. Победителей ведь не судят, да? Проблема в том, что вкладывая иной смысл в данный термин, GoF при этом ссылается на исходную статью! Более того, в первом абзаце GoF почти-почти подводят к исходному смыслу, но потом вдруг резко «обрывают» это обсуждение фразой о том, что вроде как можно «оригинальное» делегирование проэмулировать передачей параметра (что на самом деле искажает исходную идею), а в следующем абзаце с примером про это вообще «забывают». Вот это уже реальная путаница (см., например,
соответствующий вопрос.
Вот автор и «предъявляет претензии» к этой самой путанице. А заодно — «я так думаю!»(с) — и тем обстоятельством, что эта путаница является симптомом недопонимания обществом фундаментальных принципов ООП.
В качестве иллюстрации к результатам этой путаницы можно взять ваше заключительное утверждение — ведь поведенческий паттерн «цепочка обязанностей» к «делегированию» имеет отношения еще меньше отношения.
…Претензии автора максимально четко описаны в третьем абзаце:
Книга «Банды четырёх» «Шаблоны проектирования» даёт нам общий словарь для понимания базовых шаблонов ООП. Она помогает нам использовать одинаковую терминологию при обсуждении софта. К сожалению, она же является причиной путаницы.
Далее по тексту все «разжевано»:
Во-первых, к моменту публикации GoF термин «делегирование» уже был «занят» — дана ссылка на статью, где смысл термина подробно расписан. В науке принято использовать уже «занятые» термины в соответствии с той смысловой нагрузкой, которую в них вложил автор термина. В GoF, если посмотреть на пример c Окном и Прямоугольником, паттерн «делегирование» имеет смысл, отличный от вложенного в этот термин в статье 1986 года.
Но это лишь полбеды — в конце концов, GoF на порядки более известен, чем та статья, так что можно. Победителей ведь не судят, да? Проблема в том, что вкладывая иной смысл в данный термин, GoF при этом ссылается на исходную статью! Более того, в первом абзаце GoF почти-почти подводят к исходному смыслу, но потом вдруг резко «обрывают» это обсуждение фразой о том, что вроде как можно «оригинальное» делегирование проэмулировать передачей параметра (что на самом деле искажает исходную идею), а в следующем абзаце с примером про это вообще «забывают». Вот это уже реальная путаница (см., например,
соответствующий вопрос.
Вот автор и «предъявляет претензии» к этой самой путанице. А заодно — «я так думаю!»(с) — и тем обстоятельством, что эта путаница является симптомом недопонимания обществом фундаментальных принципов ООП.
В качестве иллюстрации к результатам этой путаницы можно взять ваше заключительное утверждение — ведь поведенческий паттерн «цепочка обязанностей» к «делегированию» имеет отношения еще меньше отношения.
Не, ну ок. Программисты и архитекторы прежде всего инженеры и какое-то право первенства на термин их мало интересует. И они продолжат называть делегированием всё, где реализация поведения делегируется (наверное в житейском смысле) другому объекту.
У меня также есть некоторые сомнения, что у Либермана были/есть претензии к такому общему пониманию делегирования. Возможно, он тоже в качестве примера приводил частный случай, и согласился бы с GoF в их понимании. Я не углублялся, статью не читал, и не собираюсь.
В любом случае, GoF просто делают революцию в мышлении созревшего к ней разработчика. И дают мощный словарь, сильно повышая уровень коммуникаций в команде. И это единственное, что имеет значение, но никак не какие-то академические тёрки про специфичное взаимодействие объектов в экзотических языках, за которым кто-то где-то решил застолбить термин.
У меня также есть некоторые сомнения, что у Либермана были/есть претензии к такому общему пониманию делегирования. Возможно, он тоже в качестве примера приводил частный случай, и согласился бы с GoF в их понимании. Я не углублялся, статью не читал, и не собираюсь.
В любом случае, GoF просто делают революцию в мышлении созревшего к ней разработчика. И дают мощный словарь, сильно повышая уровень коммуникаций в команде. И это единственное, что имеет значение, но никак не какие-то академические тёрки про специфичное взаимодействие объектов в экзотических языках, за которым кто-то где-то решил застолбить термин.
Вы так и не поняли, что речь не о «каких-то академических тёрках»? Жаль… Жаль даже не конкретно вас (наверняка, вы и без понимания проживете), а то, что подход типа «Я не углублялся, статью не читал, и не собираюсь. …Но мнение имею» — сегодня доминирующий. В результате имеем то, что имеет нас :)
подход типа «Я не углублялся, статью не читал, и не собираюсь. …Но мнение имею» — сегодня доминирующий. В результате имеем то, что имеет нас
Вот только в данном-то случае этот подход сработал. Andruh прав в том, что GOF корректно вычленили из оригинальной статье собственно паттерн и отбросили особенности частной реализации в условиях специфического ЯП.
Читать не собираюсь, и объяснил почему: GoF даёт результат, а эта holy war за термин — всего лишь holy war. Просто непродуктивное времяпреровождение чтение этой статьи. И ещё, очень мало конструктива что в этой habr-статье, что у вас, в основном превалируют частицы «не». Ни вы, ни автор статьи не убедили, что это имеет какой-то практический смысл — не называть делегированием то, что всеми понимается как делегирование с точки зрения здравого смысла. Всё что вы делаете — говорите, что кто-то зарезервировал это слово раньше. И все чудовищно ошибаются, делают не то.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Банда четырёх» была неправа, а вы не знаете, что такое делегирование