Шаблон проектирования команд - позволяет различным конкретным командам возвращать разные типы

Question

Мы разрабатываем новый компонент и рассматриваем использование шаблона проектирования команд.

У нас есть два основных типа команд, которые будут реализовывать наш интерфейс IOurCommand (из которого наследуются другие команды).

Вопрос заключается в том, что первая команда CommandDoUpdates не нужно возвращать какое-либо значение, в то время как вторая команда CommandGetData является извлечение данных, поэтому он должен вернуть List некоторых объектов (List<DataRow>)

вещи, которые мы принимая во внимание, чтобы справиться с ситуацией:

1. Возврат класса, который будет содержать указание об успехе операции (бонус) и список объектов, которые будут пустой список для всех на CommandDoUpdates.
2. Держите List в качестве члена конкретной команды. Потенциальное решение, но делает нашу жизнь труднее по другим причинам (мелкая копия Vs. Deep copy и т. Д.).
3. То же, что и # 1, но возвратите базовый класс в функцию, и каждый вызывающий calss должен будет придать результат конкретному классу (Down cast не является хорошей практикой, так как клиенту нужно будет знать, что такое фактическое возвращаемое значение).
4. Разбиение команды на две разные иерархии (одна, которая возвращает значение, а другая - нет) и использование двух разных ресиверов - мне это действительно не нравится, но это вариант.

This Сообщение хорошее чтение о том, должна ли команда возвращать значение/статус или нет. Это актуально, так как в книге GoF шаблон структуры команды не возвращает значение.

Мои фактические вопросы:

• Можете ли вы придумать лучшего решения?
• Любые плюсы или минусы для вариантов 1,2 и 3, любые профи для варианта 4?

Спасибо!

Answer 1

Я подозреваю, что шаблон команды расширяется до такой степени, что он действительно разбивает шаблон здесь. Один из комментариев в сообщении, который вы связали, сказал это хорошо: «Исходным намерением этого шаблона является то, что есть какой-то объект, который выполняет команды, но не знает, что они на самом деле делают». Если одно семейство команд предназначено для доступа к данным, а другое - для его мутации, действительно ли существует общий прецедент, который требует абстрагирования их на общий тип? Для меня общий интерфейс говорит, что два объекта используются одинаково, но на самом деле это не так.

Что касается лучшего решения, одним из распространенных решений является использование шаблона MV * (MVC, MVP, MVVM) и обновление команды модели и уведомление наблюдателей после обновления.

Если MV * слишком много шаблонов для вас, то я думаю, что 4 - ваш ответ, просто избавитесь от общего интерфейса. Вы не обязательно должны иметь два приемника, так как вы можете сделать метод на получателе общим. Тем не менее, я думаю, вам нужно сделать что-то другое в зависимости от того, обрабатываете ли вы CommandDoUpdates или CommandGetData, поэтому перегрузка метода может быть более понятной, чем проверка типа возвращаемого значения «command».Я думаю, что в этом случае более ясно, что подпись для вашего приемника говорит, что он получает сообщения от двух разных типов объектов, чем сказать, что эти «команды» принципиально одного типа.

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

Answer 2

В качестве альтернативы вы могли бы сделать Command, который должен возвращать результат:

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

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