Чи можна втілити стратегію без значних розгалужень?

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

Завод:

// All of these classes implement OrderStrategy
switch (orderType) {
case NEW_ORDER: return new NewOrder();
case CANCELLATION: return new Cancellation();
case RETURN: return new Return();
}

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

<strategies>
   <order type="NEW_ORDER">com.company.NewOrder</order>
   <order type="CANCELLATION">com.company.Cancellation</order>
   <order type="RETURN">com.company.Return</order>
</strategies>

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

Крім того, такий тип конструкції не добре перевіряє інтеграцію. Кожна окрема стратегія може бути простішою для перевірки, але кожна нова стратегія, яку ви додаєте, є складністю для тестування. Це менше, ніж у вас, якби ви не використовували шаблон, але він все ще є.

Чи є спосіб реалізувати стратегію, що зменшує цю складність? Або це просто так просто, як це стає, і намагання йти далі, лише додасть ще один шар абстракції за мало користі?

Звичайно, ні. Навіть якщо ви використовуєте контейнер IoC, вам доведеться десь мати умови, вирішуючи, яку конкретну реалізацію вводити. Така природа стратегії.

Я не розумію, чому люди вважають, що це проблема. У деяких книгах є твердження, як, наприклад, Фоулер Refactoring , що якщо ви бачите перемикач / корпус або ланцюжок if / elses посеред іншого коду, вам слід врахувати цей запах і поглянути, щоб перенести його на свій власний метод. Якщо код у кожному випадку більше, ніж рядок, може бути два, то слід розглянути можливість зробити цей метод заводським методом, повертаючи Стратегії.

Деякі люди вважають, що перемикач / випадок поганий. Це не так. Але він повинен проживати самостійно, якщо це можливо.

Чи можна втілити стратегію без значних розгалужень?

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

Class strategyType = allStrategies[orderType];
return runtime.create(strategyType);

Кожна реалізація стратегії повинна реєструвати фабрику з її порядком типу та деякою інформацією про те, як створити клас.

factory.register(NEW_ORDER, NewOrder.class);

Ви можете використовувати статичний конструктор для реєстрації, якщо ваша мова це підтримує.

Метод реєстрації не має нічого іншого, як додавання нового значення до хешмапу:

void register(OrderType orderType, Class class)
{
   allStrategies[orderType] = class;
}

[оновлення 2012-05-04]
Це рішення набагато складніше, ніж оригінальне "рішення комутатора", яке я б віддав перевагу більшість часу.

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

"Стратегія" полягає в тому, щоб хоча б один раз вибирати між альтернативними алгоритмами , не менше. Десь у вашій програмі хтось повинен прийняти рішення - можливо, користувач або ваша програма. Якщо ви використовуєте IoC, відображення, оцінювач файлів даних або конструкцію комутатора / випадку, щоб це здійснити, ситуація не зміниться.

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

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

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

enum FactoryType {
   Type1(Type1.class),
   Type2(Type2.class);

   private Class<? extends Type> clazz;

   private FactoryType(Class<? extends Type> clazz) {
      this.clazz = clazz;
   }

   public Class<? extends Type> getTypeClass() {
      return clazz;
   }
}

Це різко знижує заводський код:

public Type create(FactoryType type) throws Exception {
   return type.getTypeClass().newInstance();
}

(Будь ласка, ігноруйте погану обробку помилок - приклад коду :))

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

Розширення можна покращити, якщо кожен клас визначить свій тип замовлення. Тоді ваша фабрика вибирає ту, яка відповідає.

Наприклад:

public interface IOrderStrategy
{
    OrderType OrderType { get; }
}

public class NewOrder : IOrderStrategy
{
    public OrderType OrderType { get; } = OrderType.NewOrder;
}

public class OrderFactory
{
    private IEnumerable<IOrderStrategy> _strategies;

    public OrderFactory(IEnumerable<IOrderStrategy> strategies) // Injected by IoC container
    {
        _strategies = strategies;
    }

    public IOrderStrategy Create(OrderType orderType)
    {
        IOrderStrategy strategy = _strategies.FirstOrDefault(s => s.OrderType == orderType);

        if (strategy == null)
            throw new ArgumentException("Invalid order type.", nameof(orderType));

        return strategy;
    }
}

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

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

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