Великі оператори комутатора: поганий ООП?

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

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

Я кілька разів гуглив, щоб знайти рішення, які я пам’ятаю, але, на жаль, Google сьогодні став пусткою нерелевантних результатів для багатьох видів запитів.

Чи існують якісь закономірності для такого роду проблем? Будь-які пропозиції щодо можливих реалізацій?

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

Однак це також має проблему вибуху типу. Зараз мені потрібно 100 нових класів, а також я повинен знайти спосіб їх чистого інтерфейсу до моделі даних. Чи справді "одне справжнє твердження про перемикання"?

Буду вдячний за ваші думки, думки чи коментарі.

Ви можете отримати деяку користь від командного шаблону .

Що стосується ООП, ви можете згорнути кілька подібних команд, кожна в один клас, якщо варіації поведінки досить малі, щоб уникнути повного вибуху класу (так, я вже чую, як гуру ООП про це кричать). Однак, якщо система вже є ООП, і кожна з команд 100+ справді унікальна, тоді просто зробіть з них унікальні класи та скористайтесь перевагами успадкування для консолідації загальних матеріалів.

Якщо система не є ООП, то я б не додав ООП лише для цього ... Ви можете легко використовувати Шаблон команди за допомогою простого пошуку словника та покажчиків функцій, або навіть динамічно генерованих викликів функцій на основі імені команди, залежно від мову. Потім ви можете просто згрупувати логічно пов'язані функції у бібліотеки, що представляють набір подібних команд, щоб досягти керованого розділення. Я не знаю, чи є хороший термін для такого роду реалізації ... Я завжди вважаю це стилем "диспетчера", заснованим на підході MVC до обробки URL-адрес.

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

switch (eFoo)
{
case Foo.This:
  eatThis();
  break;
case Foo.That:
  eatThat();
  break;
}

switch (eFoo)
{
case Foo.This:
  drinkThis();
  break;
case Foo.That:
  drinkThat();
  break;
}

... можливо, слід переписати як ...

IAbstract
{
  void eat();
  void drink();
}

class This : IAbstract
{
  void eat() { ... }
  void drink() { ... }
}

class That : IAbstract
{
  void eat() { ... }
  void drink() { ... }
}

Однак одне твердження switch не є настільки сильним показником, що оператор switch слід замінювати чимось іншим.

Команда може бути однією із 100 різних команд

Якщо вам потрібно зробити одну із 100 різних речей, ви не можете уникнути наявності 100-бічної гілки. Ви можете кодувати його в потоці керування (перемикач, if-elseif ^ 100) або в даних (100-елементна карта від рядка до команди / заводу / стратегії). Але воно буде там.

Ви можете спробувати відокремити результат 100-сторонньої гілки від речей, яким не потрібно знати цей результат. Можливо, просто 100 різних методів це нормально; немає необхідності винаходити непотрібні вам об’єкти, якщо це робить код громіздким.

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

Я бачу схему стратегії. Якщо у мене є 100 різних стратегій ... нехай буде. Заява про гігантські перемикачі потворна. Чи всі команди є дійсними іменами класів? Якщо так, просто використовуйте імена команд як імена класів і створіть об'єкт стратегії за допомогою Activator.CreateInstance.

Є дві речі, які спадають на думку, коли говорите про велике твердження перемикача:

1. Це порушує OCP - ви можете постійно підтримувати великі функції.
2. У вас можуть бути погані показники: O (n).

З іншого боку, реалізація карти може відповідати OCP і може працювати з потенційно O (1).

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

Я переживав це в одному проекті сам, коли все більше і більше коду входило в комутатор, поки він не став неможливим. Моє рішення полягало у визначенні класу параметрів, який містив контекст для команд (ім’я, параметри, будь-що, зібране перед перемиканням), створення методу для кожного оператора case та виклик цього методу з об’єктом параметра з справи.

Звичайно, повністю диспетчер команд OOP (заснований на магії, такій як відображення або механізми, як активація Java), є красивішим, але іноді вам просто потрібно виправити ситуацію та виконати роботу;)

Ви можете використовувати словник (або хеш-карту, якщо ви кодуєте на Java) (це називає Стів Макконнелл, керований таблицею).

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

Найкращий спосіб вирішити цю конкретну проблему: чисто серіалізація та протоколи - це використання IDL та генерація коду маршалінгу з операторами switch. Оскільки незалежно від того, які шаблони (фабрика прототипів, шаблон команд тощо) ви намагаєтесь використовувати інакше, вам потрібно буде якось ініціалізувати відображення між ідентифікатором команди / рядком та покажчиком класу / функції, і він буде працювати повільніше, ніж оператори switch, оскільки компілятор може використовувати ідеальний хеш-пошук для операторів перемикання.

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

Ви також можете скористатися мовним підходом і визначити команди з відповідними даними в граматиці. Потім ви можете використовувати інструмент генератора для синтаксичного аналізу мови. Для цього я використав « Іронію» . В якості альтернативи ви можете використовувати шаблон Interpreter.

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

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

switch(id)
    case 1: DoSomething(url_1) break;
    case 2: DoSomething(url_2) break;
    ..
    ..
    case 100 DoSomething(url_100) break;

і я змінився на:

string url =  GetUrl(id);  
DoSomthing(url);

GetUrl може перейти до БД і повернути URL-адресу, яку ви шукаєте, або це може бути словник в пам'яті, що містить 100 URL-адрес. Я сподіваюся, це може допомогти кожному, хто замінює величезні жахливі заяви про перемикання.

Подумайте, як Windows була спочатку написана в насосі повідомлення програми. Це смоктало. Додатки працюватимуть повільніше, додавши більше опцій меню. Оскільки команда, яку шукали, закінчувалася все далі до нижньої частини оператора перемикання, все частіше чекали відповіді. Неприйнятно мати довгі оператори перемикання, крапка. Я створив демон AIX як обробник команд POS, який може обробляти 256 унікальних команд, навіть не знаючи, що знаходиться в потоці запитів, отриманих через TCP / IP. Найпершим символом потоку був індекс масиву функцій. Для будь-якого індексу, який не використовувався, встановлено обробник повідомлень за замовчуванням; увійти і попрощатися.