Действительно ли это - шаблон разработки?

Я видел это как шаблон команды .

Я впервые узнал о он читает Agile Принципы, Шаблоны и Практики Дяди Боба в C # . 1287 Я верю, что его элегантность - это простота. Я использовал его, когда написал сервис обработки файлов. Сервис выполняет все администрирование чтения / удаления файлов. Когда файл нужно было обработать, был загружен соответствующий плагин. Каждый плагин реализовал метод Process и делал все необходимое для обработки файлов этого типа. (Главным образом, проанализируйте содержимое и вставьте в базу данных.)

Каждый раз, когда мне приходилось обрабатывать новый тип файла с новым макетом, все, что мне нужно было сделать, это создать новый плагин, который реализовывал процесс . 1289 Это сработало для меня, потому что мне нужно было простое решение. Если вам нужно принять более одного параметра, вероятно, это не тот шаблон, который нужно использовать.

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

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

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

As It was said it is a Command Design Pattern. But it is ( as for me ) more like Java way of achieving the result. In C# you can use delegates and in the C++ function pointers and functors.

There is no big sense to create more and more classes if you already have some implementation of the reaction in a some Class method. Which you can bind in the C++ or set to delegate in the C#. In Java I suppose you have no choice but to write the code you have found.

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

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

Может быть, как предлагали некоторые из предыдущих постеров: http://en.wikipedia.org/wiki/Command_pattern

Вы можете удалить это повторение (или запретить его для будущего кода), используя лямбда-выражения. Лямбда-выражения как раз для этой ситуации.

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

Если что, то это функтор. Он используется в языках без функций первого класса (указателя) для того, для чего используются функции (указатели), например, для основной функции потока.

Существуют приложения для интерфейсов только с одним методом. Я имею в виду, что в .NET есть много - INotifyPropertyChanged, для одного (событие PropertyChanged). Это просто гарантирует, что у объекта есть определенный метод (независимо от того, к какому типу он относится в действительности), поэтому вы можете вызывать его (опять же, независимо от типа).

Dim runnableObjects As List(Of Object)
runnableObjects.Add(New MyRunnableObject1)
runnableObjects.Add(New MyRunnableObject2)

For Each o As IRunnable In runnableObjects
  o.Run()
Next