Existe um padrão de design para remover a necessidade de verificar sinalizadores?

Vou salvar uma carga útil de string no banco de dados. Eu tenho duas configurações globais:

• criptografia
• compressão

Eles podem ser ativados ou desativados usando a configuração de maneira que apenas um deles esteja ativado, ambos estejam ativados ou desativados.

Minha implementação atual é esta:

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

Estou pensando no padrão Decorator. É a escolha certa ou existe talvez uma alternativa melhor?

Ao criar código, você sempre tem duas opções.

1. basta fazê-lo, caso em que praticamente qualquer solução funcionará para você
2. ser pedante e projetar uma solução que explore as peculiaridades da linguagem e sua ideologia (linguagens OO, neste caso - o uso do polimorfismo como um meio para fornecer a decisão)

Não vou me concentrar no primeiro dos dois, porque realmente não há nada a ser dito. Se você quiser que ele funcione, deixe o código como está.

Mas o que aconteceria, se você escolhesse fazê-lo da maneira pedante e realmente resolvesse o problema com os padrões de design, da maneira que queria?

Você pode observar o seguinte processo:

Ao projetar o código OO, a maioria dos ifs que estão em um código não precisa estar lá. Naturalmente, se você deseja comparar dois tipos escalares, como ints ou floats, é provável que tenha um if, mas se desejar alterar os procedimentos com base na configuração, poderá usar o polimorfismo para obter o que deseja, mover as decisões (o ifs) da lógica de negócios para um local onde os objetos são instanciados - para as fábricas .

A partir de agora, seu processo pode percorrer 4 caminhos separados:

1. datanão é criptografado nem compactado (não ligue, retorne data)
2. dataestá compactado (ligue compress(data)e retorne)
3. dataestá criptografado (ligue encrypt(data)e devolva)
4. dataestá compactado e criptografado (chame encrypt(compress(data))e devolva)

Apenas olhando os 4 caminhos, você encontra um problema.

Você tem um processo que chama 3 (teoricamente 4, se você não contar nada como um) métodos diferentes que manipulam os dados e os retornam. Os métodos têm nomes diferentes , diferente da API pública (a maneira pela qual os métodos comunicam seu comportamento).

Usando o padrão do adaptador , podemos resolver a colisão de nomes (podemos unir a API pública) que ocorreu. Simplificando, o adaptador ajuda duas interfaces incompatíveis a trabalharem juntas. Além disso, o adaptador funciona definindo uma nova interface do adaptador, que as classes que tentam unir sua API implementam.

Esta não é uma linguagem concreta. É uma abordagem genérica, a palavra-chave any está lá para representar que pode ser de qualquer tipo, em uma linguagem como C #, você pode substituí-la por genéricos ( <T>).

Suponho que agora você pode ter duas classes responsáveis ​​pela compactação e criptografia.

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

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

No mundo corporativo, mesmo essas classes específicas provavelmente serão substituídas por interfaces, como a classpalavra - chave seria substituída por interface(se você estiver lidando com linguagens como C #, Java e / ou PHP) ou a classpalavra - chave permaneceria, mas o Compresse Encryptmétodos seriam definidos como um virtual puro , caso você codifique em C ++.

Para fazer um adaptador, definimos uma interface comum.

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

Então temos que fornecer implementações da interface para torná-la útil.

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

Ao fazer isso, você acaba com 4 classes, cada uma fazendo algo completamente diferente, mas cada uma delas fornecendo a mesma API pública. O Processmétodo

Na sua lógica de negócios, onde você lida com a decisão none / encryption / compressão / both, você projetará seu objeto para fazê-lo depender da DataProcessinginterface que projetamos anteriormente.

class DataService
{
    private dataProcessing : DataProcessing;

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

O processo em si pode ser tão simples como este:

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

    // ... perhaps work with the data

    return data;
}

Não há mais condicionais. A turma DataServicenão tem idéia do que realmente será feito com os dados quando eles forem passados ​​para o dataProcessingmembro, e realmente não se importa com isso, não é de sua responsabilidade.

Idealmente, você teria testes de unidade testando as 4 classes de adaptadores que você criou para garantir que funcionem e faça seu teste ser aprovado. E se eles forem aprovados, você pode ter certeza de que eles funcionarão, não importa onde você os chame em seu código.

Então, fazendo assim, nunca mais terei ifs no meu código?

Não. É menos provável que você tenha condicionais na lógica de negócios, mas eles ainda precisam estar em algum lugar. O lugar é suas fábricas.

E isso é bom. Você separa as preocupações da criação e realmente usa o código. Se você torna suas fábricas confiáveis ​​(em Java, você pode até usar algo como a estrutura Guice do Google), em sua lógica de negócios, não está preocupado em escolher a classe certa a ser injetada. Porque você sabe que suas fábricas funcionam e entregará o que é pedido.

É necessário ter todas essas classes, interfaces etc.?

Isso nos leva de volta ao começo.

No OOP, se você escolher o caminho para usar o polimorfismo, realmente deseja usar padrões de design, deseja explorar os recursos da linguagem e / ou deseja seguir a ideologia de tudo é um objeto, então é. E mesmo assim, este exemplo não mesmo mostrar todas as fábricas que você vai precisar e se você tivesse que refazer os Compressione Encryptionaulas e torná-los interface em vez disso, você tem que incluir suas implementações bem.

No final, você acaba com centenas de pequenas classes e interfaces, focadas em coisas muito específicas. O que não é necessariamente ruim, mas pode não ser a melhor solução para você, se tudo o que você deseja é fazer algo tão simples quanto adicionar dois números.

Se você deseja fazê-lo rapidamente, pode pegar a solução do Ixrec , que pelo menos conseguiu eliminar os blocos else ife else, que, na minha opinião, são até um pouco piores que os comuns if.

_{Leve em consideração que esta é a minha maneira de criar um bom design de OO. Codificando para interfaces em vez de implementações, é assim que eu faço nos últimos anos e é com essa abordagem que me sinto mais confortável.}

_{Eu pessoalmente gosto mais da programação if-less e gostaria muito mais da solução mais longa nas 5 linhas de código. É o modo como estou acostumado a projetar código e me sinto muito confortável em lê-lo.}

Atualização 2: Houve uma discussão selvagem sobre a primeira versão da minha solução. Discussão causada principalmente por mim, pela qual peço desculpas.

Decidi editar a resposta de uma maneira que é uma das maneiras de olhar para a solução, mas não a única. Também removi a parte do decorador, onde eu quis dizer fachada, que no final decidi deixar de fora completamente, porque um adaptador é uma variação da fachada.

O único problema que vejo no seu código atual é o risco de explosão combinatória à medida que você adiciona mais configurações, que podem ser facilmente mitigadas estruturando o código da seguinte maneira:

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

_{Não conheço nenhum "padrão de design" ou "idioma" do qual possa ser considerado um exemplo.}

Eu acho que sua pergunta não está procurando praticidade, nesse caso a resposta do lxrec é a correta, mas para aprender sobre padrões de design.

Obviamente, o padrão de comando é um exagero para um problema tão trivial quanto o que você propõe, mas para fins de ilustração, aqui está:

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

Como você vê, colocar os comandos / transformação em uma lista permite que eles sejam executados sequencialmente. Obviamente, ele executará ambos, ou apenas um deles dependerá do que você colocar na lista sem as condições.

Obviamente, os condicionais terminarão em algum tipo de fábrica que reúne a lista de comandos.

EDITAR para o comentário de @ texacre:

Existem muitas maneiras de evitar as condições if na parte criadora da solução, vamos usar, por exemplo, um aplicativo GUI de desktop . Você pode ter caixas de seleção para as opções de compactar e criptografar. No on cliccaso dessas caixas de seleção, instancie o comando correspondente e adicione-o à lista ou remova-o da lista se estiver desmarcando a opção.

Eu acho que os "padrões de design" são desnecessariamente direcionados para "oo padrões" e evitam completamente idéias muito mais simples. O que estamos falando aqui é um pipeline de dados (simples).

Eu tentaria fazê-lo em clojure. Qualquer outro idioma em que as funções sejam de primeira classe provavelmente também está ok. Talvez eu pudesse um exemplo de C # mais tarde, mas não é tão bom. Minha maneira de resolver isso seria os seguintes passos com algumas explicações para não-clojurianos:

1. Represente um conjunto de transformações.

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

Este é um mapa, ou seja, uma tabela de pesquisa / dicionário / o que for, de palavras-chave a funções. Outro exemplo (palavras-chave para strings):

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

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

Então, escrevendo (transformations :encrypt)ou (:encrypt transformations)retornaria a função de criptografia. ( (fn [data] ... )é apenas uma função lambda.)

2. Obtenha as opções como uma sequência de palavras-chave:

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

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

3. Filtre todas as transformações usando as opções fornecidas.

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

Exemplo:

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

4. Combine funções em uma:

(apply comp transformations-to-run)

Exemplo:

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

5. E então juntos:

(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])

O ONLY muda se queremos adicionar uma nova função, digamos "debug-print", é o seguinte:

(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

[Essencialmente, minha resposta é uma continuação da resposta de @Ixrec acima . ]

Uma pergunta importante: o número de combinações distintas que você precisa cobrir vai crescer? Você conhece melhor o seu domínio de assunto. Este é o seu julgamento a fazer.
O número de variantes pode aumentar? Bem, isso não é inconcebível. Por exemplo, pode ser necessário acomodar mais algoritmos de criptografia diferentes.

Se você antecipar que o número de combinações distintas aumentará, o padrão de estratégia poderá ajudá-lo. Ele foi projetado para encapsular algoritmos e fornecer uma interface intercambiável para o código de chamada. Você ainda teria uma pequena quantidade de lógica ao criar (instanciar) a estratégia apropriada para cada sequência específica.

Você comentou acima que não espera que os requisitos sejam alterados. Se você não espera que o número de variantes aumente (ou se você pode adiar essa refatoração), mantenha a lógica do jeito que está. Atualmente, você tem uma quantidade pequena e gerenciável de lógica. (Talvez faça uma observação nos comentários sobre uma possível refatoração para um padrão de estratégia.)

Uma maneira de fazer isso no scala seria:

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)

Usar o padrão decorador para atingir os objetivos acima (separação da lógica de processamento individual e como eles se conectam) seria muito detalhado.

Onde você exigiria um padrão de design para atingir esses objetivos em um paradigma de programação OO, a linguagem funcional oferece suporte nativo usando funções como cidadãos de primeira classe (linhas 1 e 2 no código) e composição funcional (linha 3)