LINUX.ORG.RU

Чем паттерн Command отличается от замыканий?

 


0

2

Читаю про паттерн Command. Это интерфейс с одним методом. И суть в том, что в объектах классов, реализующих интерфейс, при создании сохраняются нужные данные. Потом те, кому нужно, дёргают метод и он вызывает метод другого объекта, передавая ему сохранённые в объекте-команде данные в виде аргументов.

По-моему, это ничем не отличается от замыканий. Зачем было изобретать новое название для того, что известно с 60-х годов? И ещё врать, что этот паттерн изобрели в 90-е?

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

noconformism ()

можно вот так разобрать по частям. Цитата из википедии:

Четыре термина всегда связанны с шаблоном Команда: команды (command), приёмник команд (receiver), вызывающий команды (invoker) и клиент (client)

Назовите по аналогии 4 компонента замыкания, которые соответствуют этим терминам паттерна, будет ясней предмет обсуждения

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

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

noconformism ()

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

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

В паттерне Command и не нужно наследование. Есть интерфейс и есть его реализации. Наследование от абстрактного класса это просто метод сымитировать интерфейсы в языках, в которых их нет. Вызов через виртуальные функции — это деталь реализации, которая торчит наружу. Наследование тут не выполняет роли показать отношение is-a в классическом смысле «кошка это животное, поэтому наследуем Cat от Animal».

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

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

В паттерне Command и не нужно наследование

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

Наследование от абстрактного класса

А почему обязательно от абстрактного?

В языках с поддержкой замыканий не нужно забивать голову деталями реализации замыкания

Ну, чтобы понимать, как работает замыкание, нужно понимать в общих чертах ее реализацию, а именно — то, что это набор функция + окружение, по сути, латентный объект с одним единственным публичным методом:)

noconformism ()

Да у нас тут битва двух якодзун.

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

скорее одного и того же анонiмуса в разной фазе мозговой деятельности.

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

плшюками наследования Вы не сможете тогда воспользоваться.

В этом паттерне нет никаких плюшек от наследования.

А ООП без наследования — это как то странно.

Т.е. раз есть возможность наследования — будем наследоваться, даже если это не нужно? Ради идеи?

это набор функция + окружение, по сути, латентный объект

Я предпочитаю не переписывать историю. Замыкания с нами с зари развития выч. техники и никакие относительно новые баззворды типа «объект», «наследование» и т.д. не отменят этого факта.

anon_2018 ()

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

https://www.linux.org.ru/people/I-Love-Microsoft/profile

Полное имя: Steve Ballmer

Как много вы знаете нормальных психически здоровых людей, считающих, что они — Стив Баллмер? (кроме самого Стива Баллмера, естественно).

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

Замыкания с нами с зари развития выч. техники

Ну, тут еще не известно, что появилось раньше. В алголе была лексическая видимость, но в явном виде замыкания пошли с языка Scheme(до этого в лиспах традиционно использовалось динамическое связывание), а сам язык scheme был создан после языка Planner, и под его влиянием. В Planner объекты были уже в совершенно явном виде, в виде акторов(впоследствии именно Planner был основой для языка Smalltalk)

Т.е. раз есть возможность наследования — будем наследоваться, даже если это не нужно?

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

noconformism ()

Замыкание - одна из возможных реализаций паттерна

annulen ★★★★★ ()

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

Описал часть ООП как концепции. Причем тут патерн Команда?

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

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

anon_2018 ()

anon_2018

Дата регистрации: 28.03.2017 14:40:37

noconformism

Дата регистрации: 27.03.2017 0:55:22

Чем паттерн Command отличается от замыканий?

anon_2018 29.03.2017 15:51:53

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

noconformism (29.03.2017 16:09:19)

Сам с собой?

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

Поправил. Правда, получилось косно, но это ближе к описанию паттерна.

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

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

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

никому не известных язычков.

А вообще, эти языки вполне известны, во всяком случае, в научных кругах. Более того, эти языки оказали огромное влияние на развитие CS и индустрии в целом. Особенно Planner — там были заложены идеи и фундамент декларативного и объектно-ориентированного программирования. Это был революционный язык.

noconformism ()

Зачем было изобретать новое название для того, что известно с 60-х годов? И ещё врать, что этот паттерн изобрели в 90-е?

Я подозреваю, что для того, чтобы не учиться. Чтобы узнать про замыкания, программисту придётся выучить лямбда-исчисление и другие академические понятия. (Строго говоря, фича «замыкание» не требует фичи «анонимная функция», но обычно соседствует с ней.) Это трудно. Это болезненно для самолюбия, так как окажется, что есть люди умнее тебя — теоретики computer science, и ты у них что-то спрашиваешь, ты проситель. Приятнее развивать свою независимую «науку» по своим правилам, где ты никому ничего не должен, и у тебя свои падаваны.

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

Чтобы узнать про замыкания, программисту придётся выучить лямбда-исчисление

В лямбда-исчислении нет никаких замыканий. Более того, понятие замыкание в этом_вот_смысле не упоминается даже в сколько-нибудь серьезной литературе. В частности, в SICP нет ни одного упоминания этого слова, ни в разделе модели вычислений с окружениями, где вводится эта модель, ни позже.

Строго говоря, фича «замыкание» не требует фичи «анонимная функция», но обычно соседствует с ней

строго говоря, эти два понятия не имеют друг к другу ровно никакого отношения.

теоретики computer science

То есть, ООП не является частью CS? Отстали, значит мы от поколения пепси. Там нынче покемоны в этих ваших CS в моде, или кто?

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

в SICP нет ни одного упоминания этого слова

SICP:

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

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

Не читал. Он там упоминает слово замыкание именно в этом, «расхожем смысле», как функция связанная с окружением?

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

понятие замыкание в этом_вот_смысле не упоминается даже в сколько-нибудь серьезной литературе. В частности, в SICP нет ни одного упоминания этого слова

Статья от Сассмена и Стила https://en.wikisource.org/wiki/Scheme:_An_Interpreter_for_Extended_Lambda_Cal... , в которой употребляется понятие «замыкание». Но, очевидно, что это совершенно не серьёзная статья ( юмористическая, была напечатана в приложении «Комьютер саентисты шутят» к журналу). Куда ей до учебника для первокурсников под названием SICP.

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

Поиск по PDF работает, мог бы и сам найти.

Also we represent the value of a \-expression by a bundle of information called a «closure,» comprising the \-expression and the environment relative to which it was evaluated.

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

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

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

Ваше лябмда-исчисление это неправильное лямбда-исчисление! Только у меня есть тайное знание правильного лямбда-исчисления!

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

В лямбда-исчислении нет никаких замыканий. Более того, понятие замыкание в этом_вот_смысле не упоминается даже в сколько-нибудь серьезной литературе. В частности, в SICP нет ни одного упоминания этого слова, ни в разделе модели вычислений с окружениями, где вводится эта модель, ни позже.

Поищите, например, фразу «closure conversion» в Google Scholar. Впрочем, это не важно. Ваши аргументы не контраргументы, а просто придирки к моим словам. Попытка перейти на личности в последнем абзаце тоже не добавляет веса вашим словам. Поэтому не вижу пользы вам возражать. Я понимаю, что мой анализ унизителен, но на личности я не переходил. Я готов услышать альтернативные гипотезы.

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

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

почитай про лямбда-исчисление, просветись. Более того, в общем случае, реализация LC в общем случае, даже не требует окружений, потому что после подстановок и редукций обращение к изначальным определениям не требуется. Там, скорей всего, это сделано либо для удобства, либо касается «расширенной» реализации, включающей сайд-эффекты

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

Простите, сарказм не обязательно означает переход на личности. Но, в любом случае, прошу прощения, я не ожидал такой чувствительности:)

noconformism ()

По-моему, это ничем не отличается от замыканий.

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

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

Осталось сообщить, за что вы: за стройную иерархию типов, реализующую тот или иной шаблон проектирования, или за возможность краткого, насколько это позволяет ЯП, выражения решения поставленной задачи?

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

насколько это позволяет ЯП

Воспитание суровым тырпрайзом и просто любовь к людям выработали привычку писать сперва понятно для манкикодеров, (вроде тех, что ставят по неопытности превыше всего краткость в духе «насколько позволяет ЯП»), и только затем - настолько кратко, насколько можно с учетом первого. Получается несколько длиннее, без выебонов, зато понятно даже обезьяне.

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

битва двух якодзун

Вспомнил этот старый боян, прослезился... Доставил, чертяка!

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

за стройную иерархию типов, реализующую тот или иной шаблон проектирования, или

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

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

В этом паттерне нет никаких плюшек от наследования.

instanceof с замыканиями не работает.

Про то, что closures are poor man's objects и наоборот, лисперы уже всё рассказали.

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

instanceof с замыканиями не работает.

А в нём есть необходимость при реализации паттерна Command?

Про то, что closures are poor man's objects и наоборот, лисперы уже всё рассказали.

Я не претендую на приоритет. Просто решил поделиться (весьма тривиальным) наблюдением, что эти две штуки похожи.

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

функции обратного вызова

Это ты так колбек обозвал?

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

Чтобы узнать про замыкания, программисту придётся выучить лямбда-исчисление и другие академические понятия.

Ну бред же, я знаю про замыкания и не знаю особо ничего про лямбда-исчисление.

Строго говоря, фича «замыкание» не требует фичи «анонимная функция», но обычно соседствует с ней

Для замыканий требуются только правильно работающие скоупы вот и все.

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

Ну бред же, я знаю про замыкания и не знаю особо ничего про лямбда-исчисление.

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

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

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

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