Как решить проблему слишком большого количества методов в командном процессоре в шаблоне команд - PullRequest
Новая
       39

Как решить проблему слишком большого количества методов в командном процессоре в шаблоне команд

0 голосов
/ 02 января 2019

Мы планируем применить шаблон команды в нашем проекте управления процессами: есть

  • Command интерфейс для реализации
  • a CommandProcessorкоторый действительно выполняет некоторую задачу

CommandProcessor передается в экземпляр Command через конструктор , так что метод execute() в Command в конечном итоге вызоветистинное выполнение в CommandProcessor

Таким образом, код CommandProcessor выглядит следующим образом: 

public class CommandProcessor {
    public doWork1() {
      //implementation
    }
    public doWork2() {
      //implementation
    }
    public doWork3() {
      //implementation
    }

    ...

    public doWork200() {
      //implementation
    }
}

Как показывает фрагмент кода, обратная сторона из шаблон команды в нашем случае использования может быть сотни команд, и поэтому CommandProcessor может быть трудно поддерживать в долгосрочной перспективе .Итак как устранить этот недостаток ?

1 Ответ

0 голосов
/ 03 января 2019

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

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

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

Обычно шаблон команды имеет один интерфейс выполнения, см. Эту статью в Википедии для описания command_pattern

Как упомянул @robert в ваших комментариях, я думаю, вам следует переосмыслить свой API.

Редактировать

После хорошего разговора с @Rui я лучше понимаю вопрос и скажу следующее.

Хотя я неправильно понял первоначальный вопрос, я все еще готов поддержать заявление о том, что необходим редизайн. В то время как шаблон команды соблюдается, я не думаю, что дух шаблона. Объект, переданный командам (commandProcessor), является получателем командных действий, но это не похоже на правильный объект. Очевидно, мне не хватает контекста, но для меня любой объект, заканчивающийся на -er, поднимает большие флаги, поскольку на самом деле это не объект, а скорее набор методов, которые воздействуют на чьи-либо данные.

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

...