Il modello di strategia può essere implementato senza ramificazioni significative?

Il modello di strategia funziona bene per evitare enormi se ... altro costrutti e rendere più facile aggiungere o sostituire funzionalità. Tuttavia, a mio avviso lascia ancora un difetto. Sembra che in ogni implementazione ci sia ancora bisogno di un costrutto ramificato. Potrebbe essere una fabbrica o un file di dati. Ad esempio, prendi un sistema di ordinazione.

Fabbrica:

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

Il codice dopo questo non deve preoccuparsi, e c'è solo un posto dove aggiungere un nuovo tipo di ordine ora, ma questa sezione di codice non è ancora estendibile. Estraerlo in un file di dati aiuta in qualche modo la leggibilità (discutibile, lo so):

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

Ma questo aggiunge ancora codice boilerplate per elaborare il file di dati - concesso, più facilmente testabile dall'unità e codice relativamente stabile, ma comunque ulteriore complessità.

Inoltre, questo tipo di costrutto non verifica bene l'integrazione. Ogni singola strategia può essere più facile da testare ora, ma ogni nuova strategia che aggiungi è una complessità aggiuntiva da testare. È meno di quello che avresti se non avessi usato il modello, ma è ancora lì.

C'è un modo per attuare il modello strategico che mitiga questa complessità? O è semplicemente così semplice, e provare ad andare oltre aggiungerebbe un altro livello di astrazione per poco o nessun beneficio?

Ovviamente no. Anche se usi un contenitore IoC, dovrai avere condizioni da qualche parte, decidere quale implementazione concreta iniettare. Questa è la natura del modello di strategia.

Non vedo davvero perché la gente pensi che questo sia un problema. Ci sono dichiarazioni in alcuni libri, come il Refactoring di Fowler , che se vedi un interruttore / caso o una catena di if / elses nel mezzo di un altro codice, dovresti considerare quell'odore e cercare di spostarlo nel suo metodo. Se il codice all'interno di ciascun caso è più di una riga, forse due, allora dovresti considerare di rendere quel metodo un Metodo di fabbrica, restituendo Strategie.

Alcune persone hanno preso questo per significare che un interruttore / caso è male. Questo non è il caso. Ma dovrebbe risiedere da solo, se possibile.

Il modello di strategia può essere implementato senza ramificazioni significative?

Sì , utilizzando una hashmap / dizionario in cui si registra ogni implementazione di strategia. Il metodo di fabbrica diventerà qualcosa di simile

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

Ogni implementazione di strategia deve registrare una factory con il suo orderType e alcune informazioni su come creare una classe.

factory.register(NEW_ORDER, NewOrder.class);

Puoi usare il costruttore statico per la registrazione, se la tua lingua lo supporta.

Il metodo register non fa altro che aggiungere un nuovo valore all'hashmap:

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

[aggiornamento 2012-05-04]
Questa soluzione è molto più complessa della "soluzione switch" originale che preferirei la maggior parte del tempo.

Tuttavia, in un ambiente in cui le strategie cambiano spesso (ovvero il calcolo del prezzo a seconda del cliente, del tempo, ...) questa soluzione hashmap combinata con un contenitore IoC potrebbe essere una buona soluzione.

La "strategia" consiste nel dover scegliere tra algoritmi alternativi almeno una volta , non meno. Da qualche parte nel tuo programma qualcuno deve prendere una decisione - forse l'utente o il tuo programma. Se si utilizza un IoC, la riflessione, un valutatore di file di dati o un costrutto switch / case per implementare ciò non cambia la situazione.

Il modello di strategia viene utilizzato quando si specificano possibili comportamenti e viene utilizzato al meglio quando si designa un gestore all'avvio. Specificare quale istanza della strategia da utilizzare può essere eseguita tramite un mediatore, il contenitore IoC standard, una fabbrica come la descrivi o semplicemente usando quella giusta in base al contesto (poiché spesso la strategia viene fornita come parte di un uso più ampio della classe che lo contiene).

Per questo tipo di comportamento in cui è necessario chiamare metodi diversi in base ai dati, suggerirei di usare i costrutti del polimorfismo forniti dal linguaggio in questione; non il modello di strategia.

Parlando con altri sviluppatori in cui lavoro, ho trovato un'altra soluzione interessante, specifica per Java, ma sono sicuro che l'idea funzioni in altre lingue. Costruisci un enum (o una mappa, non importa troppo quale) usando i riferimenti di classe e crea un'istanza usando reflection.

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;
   }
}

Ciò riduce drasticamente il codice di fabbrica:

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

(Si prega di ignorare la scarsa gestione degli errori - codice di esempio :))

Non è il più flessibile, poiché è ancora necessaria una build ... ma riduce la modifica del codice a una riga. Mi piace che i dati siano separati dal codice di fabbrica. Puoi persino fare cose come impostare i parametri usando classi / interfacce astratte per fornire un metodo comune o creare annotazioni in fase di compilazione per forzare firme di costruttori specifiche.

L'estensibilità può essere migliorata facendo in modo che ciascuna classe definisca il proprio tipo di ordine. Quindi la tua fabbrica seleziona quella che corrisponde.

Per esempio:

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;
    }
}

Penso che dovrebbe esserci un limite al numero di filiali accettabili.

Ad esempio, se ho più di otto casi all'interno della mia istruzione switch, rivaluto il mio codice e cerco ciò che posso ricodificare. Molto spesso trovo che alcuni casi possano essere raggruppati in una fabbrica separata. La mia ipotesi qui è che esiste una fabbrica che costruisce strategie.

Ad ogni modo, non puoi evitarlo e da qualche parte dovrai controllare lo stato o il tipo di oggetto con cui stai lavorando. Costruirai quindi una strategia per questo. Buona vecchia separazione delle preoccupazioni.