Разве Command Pattern не является реализацией принципа инверсии зависимостей?

Question

Командный шаблон состоит из трех основных компонентов: Invoker, Command и Receiver. Клиент предоставляет Invoker информацию, необходимую для вызова определенного метода M на Receiver, в то время как это объект Command (который размещен Receiver), который на самом деле вызывает M,

a) Для реализации CP мы должны отделить логику Invoker от количества команд таким образом, чтобы при увеличении количества команд класс Invoker не должен был изменяться. Мы делаем это, когда объекты Command и Invoker зависят от абстракции (т.е. интерфейса).

Таким образом, не является ли CP просто конкретной реализацией DIP?

б) Если CP действительно является реализацией DIP, то чем конкретно CP отличается от других типов реализации DIP? А именно, нельзя ли утверждать, что все другие реализации DIP также имеют объект Invoker (т. Е. Модуль более высокого уровня), объекты Command (т. Е. Зависимости, обеспечивающие поведение модуля более высокого уровня), тогда как Receiver будет рассматриваться как любой метод, являющийся объектом зависимости (т.е. модуль нижнего уровня) вызывает?

благодарю вас

РЕДАКТИРОВАТЬ:

а)

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

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

И наоборот - если Invoker всегда вызывает один и тот же объект команды, можем ли мы тогда утверждать, что у нас есть DI, а не CP, независимо от того, какой объект рабочей команды фактически выполняет?

б) Я понимаю, что вы пытаетесь сделать, но у меня все еще есть некоторые серьезные проблемы, связанные с тем, что делает поведение чем-то, а что - командой. С моей точки зрения, передача команды в Invoker также может быть интерпретирована как введение поведения, необходимого зависимому объекту для выполнения своей работы. Это действительно так ясно или более субъективно? Таким образом, как мы решаем, является ли работа, выполняемая объектом, командой или поведением?

Answer 1

Шаблон команды ничего не вводит в объект. Он передает команду методу, который вызывает команду (как правило, только один раз).

Внедрение зависимостей внедряет зависимость (то есть другой объект, необходимый зависимому объекту для выполнения своей работы). Зависимый объект сохраняет зависимость как поле и использует ее для всех последующих вызовов метода.

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

РЕДАКТИРОВАТЬ:

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

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

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

Так что мой ответ на ваш пункт а) будет: да или нет, это зависит. Если объект является общим объектом, предоставляющим различные методы и который не является одной из многих реализаций одного интерфейса с одним-единственным методом, который зависимый объект вызывает по своему усмотрению, он не представляет собой команду.

б) Прочитайте пример кода в http://en.wikipedia.org/wiki/Command_pattern, это должно сделать его более понятным.