Обработка многочисленных микрозависимостей

Question

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

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

class Service {

   void process() {
     //....
     if (client1) doStuff1();
     if (client2) doStuff2();
     //....
     if (client1) name = "xyz";
     else if (client2) name = "abc";
     //....
     if (client1) sortasc();
     else  sortdesc();
     //....
     if (client2) processx();
     else if (client3) processy();
   }

}

Answer 1

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

Но на самом деле не существует правила, согласно которому реализация имеет , одинаковую для каждого клиента. Если бы было такое правило, у вас не было бы так много исключений. Правда состоит в том, что обработка отличается для каждого клиента, и они просто оказываются в основном одинаковыми сегодня .

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

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

class Client1Service implements Service {
    void process() {
        doCommonSetup();
        doStuff1();
        doCommonThing();
        doStuffWithName("xyz");
        sortasc();
        doMoreCommonStuff();
        processy();
    }
}

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

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