Esiste un modello di progettazione per rimuovere la necessità di verificare la presenza di bandiere?

Ho intenzione di salvare un po 'di payload di stringa nel database. Ho due configurazioni globali:

• crittografia
• compressione

Questi possono essere abilitati o disabilitati usando la configurazione in modo che sia abilitato solo uno di essi, entrambi siano abilitati o entrambi siano disabilitati.

La mia attuale implementazione è questa:

if (encryptionEnable && !compressEnable) {
    encrypt(data);
} else if (!encryptionEnable && compressEnable) {
    compress(data);
} else if (encryptionEnable && compressEnable) {
    encrypt(compress(data));
} else {
  data;
}

Sto pensando al modello Decorator. È la scelta giusta o c'è forse un'alternativa migliore?

Quando si progetta il codice, sono sempre disponibili due opzioni.

1. fallo, nel qual caso praticamente qualsiasi soluzione funzionerà per te
2. essere pedanti e progettare una soluzione che sfrutti le stranezze della lingua e la sua ideologia (le lingue OO in questo caso - l'uso del polimorfismo come mezzo per fornire la decisione)

Non mi concentrerò sul primo dei due, perché non c'è davvero nulla da dire. Se volessi semplicemente farlo funzionare, potresti lasciare il codice così com'è.

Ma cosa succederebbe se scegliessi di farlo in modo pedante e risolvi effettivamente il problema con i modelli di design, nel modo in cui lo volevi?

Potresti guardare il seguente processo:

Quando si progetta il codice OO, la maggior parte degli ifs che si trovano in un codice non devono essere presenti. Naturalmente, se si desidera confrontare due tipi scalari, come ints o floats, è probabile che si abbia un if, ma se si desidera modificare le procedure in base alla configurazione, è possibile utilizzare il polimorfismo per ottenere ciò che si desidera, spostare le decisioni ifs) dalla tua logica aziendale a un luogo, dove gli oggetti sono istanziati - alle fabbriche .

A partire da ora, il tuo processo può passare attraverso 4 percorsi separati:

1. datanon è né crittografato né compresso (non chiamare nulla, restituire data)
2. dataè compresso (chiama compress(data)e restituiscilo)
3. dataè crittografato (chiamalo encrypt(data)e restituiscilo)
4. dataè compresso e crittografato (chiamalo encrypt(compress(data))e restituiscilo)

Solo guardando i 4 percorsi, trovi un problema.

Hai un processo che chiama 3 (teoricamente 4, se conti di non chiamare nulla come uno) metodi diversi che manipolano i dati e poi li restituiscono. I metodi hanno nomi diversi , differenti cosiddette API pubbliche (il modo in cui i metodi comunicano il loro comportamento).

Usando il modello dell'adattatore , possiamo risolvere la colisione del nome (possiamo unire l'API pubblica) che si è verificata. Detto semplicemente, l'adattatore aiuta due interfacce incompatibili a lavorare insieme. Inoltre, l'adattatore funziona definendo una nuova interfaccia dell'adattatore, le cui classi tentano di unire la loro implementazione API.

Questo non è un linguaggio concreto. È un approccio generico, qualsiasi parola chiave è lì per rappresentare può essere di qualsiasi tipo, in un linguaggio come C # puoi sostituirlo con generics ( <T>).

Suppongo che in questo momento puoi avere due classi responsabili della compressione e della crittografia.

class Compression
{
    Compress(data : any) : any { ... }
}

class Encryption
{
    Encrypt(data : any) : any { ... }
}

In un mondo aziendale, è molto probabile che anche queste classi specifiche vengano sostituite da interfacce, ad esempio la classparola chiave verrebbe sostituita interface(se si ha a che fare con linguaggi come C #, Java e / o PHP) o la classparola chiave rimarrebbe, ma il Compresse i Encryptmetodi verrebbero definiti come un puro virtuale , se si codifica in C ++.

Per creare un adattatore, definiamo un'interfaccia comune.

interface DataProcessing
{
    Process(data : any) : any;
}

Quindi dobbiamo fornire implementazioni dell'interfaccia per renderlo utile.

// when neither encryption nor compression is enabled
class DoNothingAdapter : DataProcessing
{
    public Process(data : any) : any
    {
        return data;
    }
}

// when only compression is enabled
class CompressionAdapter : DataProcessing
{
    private compression : Compression;

    public Process(data : any) : any
    {
        return this.compression.Compress(data);
    }
}

// when only encryption is enabled
class EncryptionAdapter : DataProcessing
{
    private encryption : Encryption;

    public Process(data : any) : any
    {
        return this.encryption.Encrypt(data);
    }
}

// when both, compression and encryption are enabled
class CompressionEncryptionAdapter : DataProcessing
{
    private compression : Compression;
    private encryption : Encryption;

    public Process(data : any) : any
    {
        return this.encryption.Encrypt(
            this.compression.Compress(data)
        );
    }
}

In questo modo, finisci con 4 classi, ognuna facendo qualcosa di completamente diverso, ma ognuna di esse fornisce la stessa API pubblica. Il Processmetodo.

Nella tua logica aziendale, in cui hai a che fare con nessuna / crittografia / compressione / entrambe le decisioni, progetterai il tuo oggetto per farlo dipendere DataProcessingdall'interfaccia che abbiamo progettato in precedenza.

class DataService
{
    private dataProcessing : DataProcessing;

    public DataService(dataProcessing : DataProcessing)
    {
        this.dataProcessing = dataProcessing;
    }
}

Il processo stesso potrebbe quindi essere semplice come questo:

public ComplicatedProcess(data : any) : any
{
    data = this.dataProcessing.Process(data);

    // ... perhaps work with the data

    return data;
}

Niente più condizionali. La classe DataServicenon ha idea di cosa verrà realmente fatto con i dati quando saranno passati al dataProcessingmembro, e non gliene importa nulla, non è sua responsabilità.

Idealmente, si avrebbero test unitari per testare le 4 classi di adattatori create per assicurarsi che funzionassero, in modo da superare il test. E se passano, puoi essere abbastanza sicuro che funzioneranno indipendentemente da dove li chiami nel tuo codice.

Così facendo così non avrò mai più ifs nel mio codice?

No. È meno probabile che tu abbia condizionali nella tua logica aziendale, ma devono comunque trovarsi da qualche parte. Il posto è le tue fabbriche.

E questo va bene. Separare le preoccupazioni relative alla creazione e all'utilizzo effettivo del codice. Se rendi le tue fabbriche affidabili (in Java potresti persino arrivare a utilizzare qualcosa come il framework Guice di Google), nella tua logica aziendale non sei preoccupato di scegliere la classe giusta da iniettare. Perché sai che le tue fabbriche funzionano e forniranno ciò che ti viene chiesto.

È necessario disporre di tutte queste classi, interfacce, ecc.?

Questo ci riporta all'inizio.

In OOP, se scegli il percorso per usare il polimorfismo, vuoi davvero usare modelli di design, vuoi sfruttare le caratteristiche del linguaggio e / o vuoi seguire il tutto è un'ideologia di oggetti, allora lo è. E anche allora, questo esempio non mostra nemmeno tutte le fabbriche che si sta per necessità e se si dovesse refactoring le Compressione Encryptionclassi e renderli interfacce, invece, è necessario includere le loro implementazioni pure.

Alla fine ti ritrovi con centinaia di piccole classi e interfacce, focalizzate su cose molto specifiche. Il che non è necessariamente negativo, ma potrebbe non essere la soluzione migliore per te se tutto ciò che vuoi è fare qualcosa di semplice come aggiungere due numeri.

Se vuoi farlo in modo rapido e veloce, puoi prendere la soluzione di Ixrec , che almeno è riuscita a eliminare i blocchi else ife else, che, secondo me, sono anche un po 'peggio di una semplice if.

_{Prendi in considerazione questo è il mio modo di realizzare un buon design OO. Codificare le interfacce piuttosto che le implementazioni, ecco come l'ho fatto negli ultimi anni ed è l'approccio con cui mi sento più a mio agio.}

_{Personalmente mi piace di più la programmazione if-less e apprezzerei molto di più la soluzione più lunga su 5 righe di codice. È il modo in cui sono abituato a progettare il codice e mi sento molto a mio agio nel leggerlo.}

Aggiornamento 2: c'è stata una discussione sfrenata sulla prima versione della mia soluzione. Discussione principalmente causata da me, per cui mi scuso.

Ho deciso di modificare la risposta in modo che sia uno dei modi per esaminare la soluzione, ma non l'unico. Ho anche rimosso la parte del decoratore, dove intendevo invece la facciata, che alla fine ho deciso di lasciare completamente, perché un adattatore è una variazione di facciata.

L'unico problema che vedo con il tuo codice attuale è il rischio di esplosione combinatoria quando aggiungi più impostazioni, che possono essere facilmente mitigate strutturando il codice in questo modo:

if(compressEnable){
  data = compress(data);
}
if(encryptionEnable) {
  data = encrypt(data);
}
return data;

_{Non sono a conoscenza di alcun "modello di progettazione" o "linguaggio" di cui questo possa essere considerato un esempio.}

Immagino che la tua domanda non stia cercando praticità, nel qual caso la risposta di lxrec è quella corretta, ma per conoscere i modelli di progettazione.

Ovviamente il modello di comando è eccessivo per un problema così banale come quello che proponi, ma per motivi di illustrazione qui va:

public interface Command {
    public String transform(String s);
}

public class CompressCommand implements Command {
    @Override
    public String transform(String s) {
        String compressedString=null;
        //Compression code here
        return compressedString;
    }
}

public class EncryptCommand implements Command {
    @Override
    public String transform(String s) {
        String EncrytedString=null;
        // Encryption code goes here
        return null;
    }

}

public class Test {
    public static void main(String[] args) {
        List<Command> commands = new ArrayList<Command>();
        commands.add(new CompressCommand());
        commands.add(new EncryptCommand()); 
        String myString="Test String";
        for (Command c: commands){
            myString = c.transform(myString);
        }
        // now myString can be stored in the database
    }
}

Come vedi mettere i comandi / trasformazione in un elenco consente di eseguirli in sequenza. Ovviamente eseguirà entrambi, o solo uno di essi dipenderà da ciò che metti nella lista senza se le condizioni.

Ovviamente i condizionali finiranno in una sorta di fabbrica che mette insieme l'elenco dei comandi.

EDIT per il commento di @ texacre:

Esistono molti modi per evitare le condizioni if ​​nella parte creazionale della soluzione, ad esempio un'app GUI desktop . È possibile disporre di caselle di controllo per le opzioni di compressione e crittografia. Nel on cliccaso in cui queste caselle di controllo si istanzino il comando corrispondente e lo si aggiunga all'elenco o si rimuova dall'elenco se si deseleziona l'opzione.

Penso che i "modelli di progettazione" siano indebitamente orientati verso "modelli oo" ed evitando completamente idee molto più semplici. Ciò di cui stiamo parlando qui è una (semplice) pipeline di dati.

Proverei a farlo con il clojure. Anche qualsiasi altra lingua in cui le funzioni sono di prima classe è probabilmente ok. Forse potrei fare un esempio in C # in seguito, ma non è così bello. Il mio modo di risolvere questo sarebbe il seguente passo con alcune spiegazioni per i non clojuriani:

1. Rappresenta una serie di trasformazioni.

(def transformations { :encrypt  (fn [data] ... ) 
                       :compress (fn [data] ... )})

Questa è una mappa, ovvero una tabella / dizionario di ricerca / qualunque cosa, dalle parole chiave alle funzioni. Un altro esempio (parole chiave per stringhe):

(def employees { :A1 "Alice" 
                 :X9 "Bob"})

(employees :A1) ; => "Alice"
(:A1 employees) ; => "Alice"

Quindi, scrivendo (transformations :encrypt)o (:encrypt transformations)restituirebbe la funzione di crittografia. ( (fn [data] ... )è solo una funzione lambda.)

2. Ottieni le opzioni come una sequenza di parole chiave:

(defn do-processing [options data] ;function definition
  ...)

(do-processing [:encrypt :compress] data) ;call to function

3. Filtra tutte le trasformazioni utilizzando le opzioni fornite.

(let [ transformations-to-run (map transformations options)] ... )

Esempio:

(map employees [:A1]) ; => ["Alice"]
(map employees [:A1 :X9]) ; => ["Alice", "Bob"]

4. Combina le funzioni in una:

(apply comp transformations-to-run)

Esempio:

(comp f g h) ;=> f(g(h()))
(apply comp [f g h]) ;=> f(g(h()))

5. E poi insieme:

(def transformations { :encrypt  (fn [data] ... ) 
                       :compress (fn [data] ... )})

(defn do-processing [options data]
  (let [transformations-to-run (map transformations options)
        selected-transformations (apply comp transformations-to-run)] 
    (selected-transformations data)))

(do-processing [:encrypt :compress])

L'UNICO cambia se vogliamo aggiungere una nuova funzione, diciamo "debug-print", è la seguente:

(def transformations { :encrypt  (fn [data] ... ) 
                       :compress (fn [data] ... )
                       :debug-print (fn [data] ...) }) ;<--- here to add as option

(defn do-processing [options data]
  (let [transformations-to-run (map transformations options)
        selected-transformations (apply comp transformations-to-run)] 
    (selected-transformations data)))

(do-processing [:encrypt :compress :debug-print]) ;<-- here to use it
(do-processing [:compress :debug-print]) ;or like this
(do-processing [:encrypt]) ;or like this

[Essenzialmente, la mia risposta è un seguito alla risposta di @Ixrec sopra . ]

Una domanda importante: il numero di combinazioni distinte che devi coprire aumenterà? Conosci meglio il tuo dominio soggetto. Questo è il tuo giudizio da esprimere.
Il numero di varianti può eventualmente aumentare? Bene, questo non è inconcepibile. Ad esempio, potrebbe essere necessario includere algoritmi di crittografia più diversi.

Se prevedi che il numero di combinazioni distinte aumenterà, il modello di strategia può aiutarti. È progettato per incapsulare algoritmi e fornire un'interfaccia intercambiabile al codice chiamante. Avresti ancora una piccola quantità di logica quando crei (crei un'istanza) la strategia appropriata per ogni stringa particolare.

Hai commentato sopra che non ti aspetti che i requisiti cambino. Se non ti aspetti che il numero di varianti aumenti (o se puoi rinviare questo refactoring), mantieni la logica così com'è. Attualmente, hai una quantità piccola e gestibile di logica. (Forse metti un commento personale nei commenti su un possibile refactoring a un modello di strategia.)

Un modo per farlo in scala sarebbe:

val handleCompression: AnyRef => AnyRef = data => if (compressEnable) compress(data) else data
val handleEncryption: AnyRef => AnyRef = data => if (encryptionEnable) encrypt(data) else data
val handleData = handleCompression andThen handleEncryption
handleData(data)

L'uso del motivo decorativo per raggiungere gli obiettivi di cui sopra (separazione della logica di elaborazione individuale e come collegano insieme) sarebbe troppo dettagliato.

Laddove avresti bisogno di un modello di progettazione per raggiungere questi obiettivi di progettazione in un paradigma di programmazione OO, il linguaggio funzionale offre supporto nativo usando funzioni come cittadini di prima classe (riga 1 e 2 nel codice) e composizione funzionale (riga 3)