Як переробляти додаток із кількома випадками комутації?

У мене є додаток, який приймає ціле число як вхідне і базується на статичних методах введення викликів різних класів. Кожного разу, коли додається нове число, нам потрібно додавати інший випадок і викликати інший статичний метод іншого класу. Зараз в комутаторі 50 випадків, і кожен раз, коли мені потрібно додати ще один випадок, я здригаюся. Чи є кращий спосіб це зробити.

Я подумав і придумав цю ідею. Я використовую стратегію. Замість того, щоб мати корпус комутатора, у мене є карта об'єктів стратегії, ключовим є вхідне ціле число. Після виклику методу він шукатиме об’єкт і викликає загальний метод для об'єкта. Таким чином я можу уникати використання конструкції корпусу комутатора.

Як ти гадаєш?

Зараз в комутаторі 50 випадків, і кожен раз, коли мені потрібно додати ще один випадок, я здригаюся.

Я люблю поліморфізм. Я люблю СОЛІД. Я люблю чисте об’єктно-орієнтоване програмування. Я ненавиджу бачити, що вони отримують погану відповідь, оскільки вони застосовуються догматично.

Ви не зробили гарного випадку, щоб переробити стратегію. Рефакторинг, до речі, має назву. Це називається Замінити умовне поліморфізмом .

Я знайшов для вас кілька відповідних порад від c2.com :

Це дійсно має сенс лише в тому випадку, якщо одні і ті ж або дуже схожі умовні тести повторюються часто. Для простих, рідко повторюваних тестів, заміна простого умовного на багатослівність визначень декількох класів і, ймовірно, переміщення всього цього далеко від коду, який насправді вимагає умовно необхідної діяльності, призведе до прикладного підручника з приводу придушення коду. Віддайте перевагу ясності перед догматичною чистотою. - DanMuller

У вас є перемикач з 50 корпусів, і ваша альтернатива - виготовити 50 об'єктів. Ой і 50 рядків коду будівництва об'єкта. Це не прогрес. Чому ні? Оскільки цей рефакторинг не робить нічого для зменшення числа з 50. Ви використовуєте цей рефакторинг, коли виявите, що вам потрібно створити ще одне повідомлення переключення на тому ж вході десь в іншому місці. Ось тоді цей рефакторинг допомагає, оскільки він перетворює 100 назад на 50.

Поки ви посилаєтесь на "перемикач" так, як це єдиний у вас є, я не рекомендую цього. Єдиною перевагою, яку ви отримаєте від рефакторингу зараз, є те, що це зменшує шанси на те, що якийсь goofball скопіює та вставить ваш 50-ти вимикач.

Я рекомендую уважно придивитися до цих 50 випадків щодо спільності, які можна визначити. Я маю на увазі 50? Дійсно? Ви впевнені, що вам потрібно стільки справ? Ви можете намагатися зробити тут багато.

Карта об'єктів стратегії тільки, яка ініціалізується в якійсь функції вашого коду, де у вас є кілька рядків коду

     myMap.Add(1,new Strategy1());
     myMap.Add(2,new Strategy2());
     myMap.Add(3,new Strategy3());

вимагає від вас та ваших колег реалізовувати функції / стратегії, які потрібно викликати в окремих класах, більш рівномірно (оскільки всі об’єкти стратегії повинні будуть реалізовувати один і той же інтерфейс). Такий код часто трохи більш вичерпний, ніж

     case 1:
          MyClass1.Doit1(someParameters);
          break;
     case 2:
          MyClass2.Doit2(someParameters);
          break;
     case 3:
          MyClass3.Doit3(someParameters);
          break;

Однак це все одно не звільнить вас від тягаря редагування цього кодового файлу, коли потрібно буде додати нове число. Справжні переваги такого підходу відрізняються:

• ініціалізація карти тепер стає відокремленою від диспетчерського коду, який фактично викликає функцію, пов'язану з певним номером, і останній більше не містить цих 50 повторень, це буде просто схоже myMap[number].DoIt(someParameters). Тому цей код відправки не потрібно торкатися кожного разу, коли надходить нове число, і він може бути реалізований за принципом відкритого закриття. Більше того, коли ви отримаєте вимоги, коли вам потрібно розширити сам код відправки, вам більше не доведеться міняти 50 місць, а лише одне.

• вміст карти визначається під час виконання (в той час як зміст конструкції комутатора визначається до моменту компіляції), тому це дає можливість зробити логіку ініціалізації більш гнучкою або розширюваною.

Так, так, є деякі переваги, і це, безумовно, крок до отримання більш SOLID-коду. Якщо це окупиться за рефактор, це те, що вам або вашій команді доведеться вирішити самостійно. Якщо ви не очікуєте, що код відправки буде змінено, зміниться логіка ініціалізації, і читабельність файлу switchне є справжньою проблемою, то ваш рефакторинг може бути вже не таким важливим.

Я категорично за стратегію, викладену у відповіді @DocBrown .

Я збираюся запропонувати відповідь покращити.

Дзвінки

 myMap.Add(1,new Strategy1());
 myMap.Add(2,new Strategy2());
 myMap.Add(3,new Strategy3());

може поширюватися. Вам не потрібно повертатися до того ж файлу, щоб додати ще одну стратегію, яка ще краще дотримується принципу Open-Closed.

Скажімо, ви реалізуєте Strategy1у файлі Strategy1.cpp. У вас може бути наступний блок коду.

namespace Strategy1_Impl
{
   struct Initializer
   {
      Initializer()
      {
         getMap().Add(1, new Strategy1());
      }
   };
}
using namespace Strategy1_Impl;

static Initializer initializer;

Ви можете повторити один і той же код у кожному файлі StategyN.cpp. Як бачите, це буде багато повторюваного коду. Щоб зменшити дублювання коду, ви можете використовувати шаблон, який можна помістити у файл, доступний для всіх Strategyкласів.

namespace StrategyHelper
{
   template <int N, typename StrategyType> struct Initializer
   {
      Initializer()
      {
         getMap().Add(N, new StrategyType());
      }
   };
}

Після цього єдине, що вам потрібно використовувати у Strategy1.cpp:

static StrategyHelper::Initializer<1, Strategy1> initializer;

Відповідний рядок у StrategyN.cpp:

static StrategyHelper::Initializer<N, StrategyN> initializer;

Ви можете перейти до використання шаблонів на інший рівень, використовуючи шаблон класу для конкретних класів стратегії.

class Strategy { ... };

template <int N> class ConcreteStrategy;

А потім замість цього Strategy1використовуйте ConcreteStrategy<1>.

template <> class ConcreteStrategy<1> : public Strategy { ... };

Змініть клас помічників для реєстрації Strategys на:

namespace StrategyHelper
{
   template <int N> struct Initializer
   {
      Initializer()
      {
         getMap().Add(N, new ConcreteStrategy<N>());
      }
   };
}

Змініть код у Strateg1.cpp на:

static StrategyHelper::Initializer<1> initializer;

Змініть код у StrategN.cpp на:

static StrategyHelper::Initializer<N> initializer;