Policy

O Policy Pattern é um padrão de design que permite definir um conjunto de regras ou políticas que governam o comportamento de um sistema. Assim como o Strategy Pattern, ele encapsula diferentes comportamentos em classes separadas, mas é mais focado na aplicação de regras de negócio ou diretrizes operacionais em sistemas complexos.

Contexto

O Policy Pattern surge da necessidade de flexibilizar e modularizar a aplicação de regras de negócio que podem variar ou ser combinadas de maneiras diferentes. Ele é comumente usado em sistemas onde as políticas podem mudar frequentemente ou onde diferentes combinações de políticas precisam ser aplicadas a diferentes contextos. Sua origem está ligada à busca por desacoplamento e reutilização de código em sistemas empresariais, onde as regras de negócio podem ser complexas e mutáveis.

Origem do Policy Pattern

O Policy Pattern não faz parte do conjunto original de padrões de design definidos pelo “Gang of Four” (GoF) em seu livro de 1994. Sua origem é mais recente e está relacionada ao desenvolvimento de software em contextos onde a modularidade e a flexibilidade na aplicação de regras de negócio se tornaram essenciais. O conceito foi proposto e popularizado em discussões sobre arquitetura de software e design patterns voltados para sistemas complexos, especialmente em trabalhos de autores como Robert C. Martin e em comunidades focadas em práticas ágeis e orientadas a objetos.

O Policy Pattern ganhou destaque como uma forma de desacoplar regras e diretrizes operacionais do código principal, permitindo que essas políticas sejam definidas, alteradas e combinadas de maneira modular. Ele é frequentemente mencionado em livros e artigos sobre design de software moderno, sendo aplicado em contextos como frameworks de segurança, sistemas de autorização e ambientes empresariais onde as regras de negócio precisam ser adaptáveis.

Essa abordagem evoluiu a partir da necessidade de aplicar princípios de design como Single Responsibility Principle (SRP) e Open/Closed Principle (OCP) em sistemas que exigem a administração dinâmica e combinatória de regras. O Policy Pattern é discutido em várias fontes, mas não possui uma única origem atribuída a um autor ou obra específica, sendo mais uma evolução do conceito de encapsulamento de comportamentos, conforme os paradigmas de desenvolvimento de software foram avançando.

Principais Componentes do Policy Pattern

O Policy Pattern é composto por alguns componentes principais que permitem a implementação e a aplicação de políticas de maneira flexível e modular. Esses componentes são:

1. Contexto (Context):
   O contexto é a classe ou objeto que precisa aplicar uma ou mais políticas. Ele interage com as políticas, delegando a elas a responsabilidade de decidir ou realizar uma ação específica. O contexto geralmente mantém uma referência às políticas relevantes e as aplica conforme necessário.
2. Interface da Política (Policy Interface):
   A interface da política define o contrato que todas as políticas devem seguir. Ela declara os métodos que as políticas concretas devem implementar, permitindo que o contexto interaja com diferentes políticas de maneira uniforme e intercambiável.
3. Políticas Concretas (Concrete Policies):
   As políticas concretas são implementações específicas da interface da política. Cada classe concreta encapsula uma regra ou comportamento específico, seguindo as diretrizes da interface. Elas contêm a lógica para executar ou verificar uma política específica.
4. Combinador de Políticas (Policy Combiner) [Opcional]:
   Em sistemas onde múltiplas políticas precisam ser aplicadas em conjunto, pode haver um componente que combina várias políticas em uma única decisão. Esse combinador pode aplicar regras de combinação como “permitir se qualquer política permitir” ou “negar se qualquer política negar”, entre outras.

Exemplo de Uso

Em um sistema de autorização, o contexto poderia ser uma classe AccessControl, a interface da política poderia definir métodos como isAllowed(User user, Resource resource), e as políticas concretas poderiam ser classes como RoleBasedPolicy e TimeBasedPolicy. O combinador de políticas poderia então determinar se o acesso é concedido com base em uma combinação dessas políticas.

Esses componentes, trabalhando juntos, permitem que o sistema aplique regras de maneira flexível e extensível, tornando-o adaptável a diferentes necessidades e cenários.

Claro! Vamos explorar um exemplo diferente. Imagine que estamos implementando um sistema de cálculo de preços de seguro, onde as políticas determinam o desconto aplicável a uma apólice com base em diversos critérios, como idade do cliente, tipo de veículo e histórico de sinistros.

Cenário: Cálculo de Desconto em Seguros

O sistema precisa aplicar diferentes políticas de desconto, como desconto para motoristas sem sinistros, desconto para veículos elétricos e desconto para clientes acima de 50 anos.

Componentes do Exemplo

1. Interface da Política: Define o contrato para todas as políticas de desconto.
2. Políticas Concretas: Implementações específicas das políticas de desconto.
3. Contexto: A classe que aplica essas políticas para calcular o desconto final em uma apólice.

Código:

from abc import ABC, abstractmethod

# Interface da Política
class DiscountPolicy(ABC):
    @abstractmethod
    def apply_discount(self, quote):
        pass

# Implementação da Política de Desconto para Motoristas Sem Sinistros
class NoClaimDiscountPolicy(DiscountPolicy):
    def apply_discount(self, quote):
        if quote.years_without_claim > 5:
            return quote.base_premium * 0.85  # 15% de desconto
        return quote.base_premium

# Implementação da Política de Desconto para Veículos Elétricos
class ElectricVehicleDiscountPolicy(DiscountPolicy):
    def apply_discount(self, quote):
        if quote.vehicle.is_electric:
            return quote.base_premium * 0.90  # 10% de desconto
        return quote.base_premium

# Implementação da Política de Desconto para Clientes acima de 50 anos
class SeniorCitizenDiscountPolicy(DiscountPolicy):
    def apply_discount(self, quote):
        if quote.client.age > 50:
            return quote.base_premium * 0.80  # 20% de desconto
        return quote.base_premium

# Classe Contexto que usa as Políticas
class InsuranceCalculator:
    def __init__(self, discount_policies):
        self.discount_policies = discount_policies

    def calculate_premium(self, quote):
        premium = quote.base_premium
        for discount_policy in self.discount_policies:
            premium = discount_policy.apply_discount(quote)
        return premium

# Classe que representa a Proposta de Seguro
class InsuranceQuote:
    def __init__(self, base_premium, years_without_claim, vehicle, client):
        self.base_premium = base_premium  # Valor base do prêmio do seguro
        self.years_without_claim = years_without_claim  # Anos sem sinistros
        self.vehicle = vehicle  # Informações sobre o veículo segurado
        self.client = client  # Informações sobre o cliente da proposta

class Vehicle:
    def __init__(self, is_electric):
        self.is_electric = is_electric

class Client:
    def __init__(self, age):
        self.age = age

# Uso do sistema
if __name__ == "__main__":
    policies = [
        NoClaimDiscountPolicy(),
        ElectricVehicleDiscountPolicy(),
        SeniorCitizenDiscountPolicy()
    ]

    calculator = InsuranceCalculator(policies)

    # Criação do objeto InsuranceQuote
    vehicle = Vehicle(is_electric=True)
    client = Client(age=55)
    quote = InsuranceQuote(base_premium=1000, years_without_claim=6, vehicle=vehicle, client=client)

    # Cálculo do prêmio final
    final_premium = calculator.calculate_premium(quote)
    print("Prêmio final:", final_premium)

Explicação do Exemplo:

• Interface da Política (DiscountPolicy): Define o método applyDiscount, que todas as políticas de desconto devem implementar.
• Políticas Concretas: Cada política concreta implementa uma regra de desconto específica, como desconto para motoristas sem sinistros, veículos elétricos ou clientes idosos.
• Contexto (InsuranceCalculator): Recebe uma lista de políticas de desconto e aplica cada uma delas para calcular o prêmio final da apólice.

Conclusão:

Neste exemplo, o Policy Pattern permite que o sistema de cálculo de seguros aplique diferentes regras de desconto de forma modular e extensível. Novas políticas de desconto podem ser adicionadas sem modificar o código existente, apenas criando novas implementações de DiscountPolicy e incluindo-as na lista de políticas do InsuranceCalculator.

Aplicabilidade

O Policy Pattern é aplicado em situações onde é necessário gerenciar múltiplas regras de negócio que podem ser combinadas ou alteradas dinamicamente. Ele é particularmente útil em:

1. Decisões Binárias (Sim ou Não):
   Em muitos casos, como em sistemas de controle de acesso, o Policy Pattern é usado para determinar se uma ação deve ser permitida ou negada. Aqui, as políticas concretas implementam regras que retornam um resultado binário.
2. Cálculo de Valores ou Parâmetros:
   O Policy Pattern pode ser usado para calcular valores ou definir parâmetros com base em regras específicas. Por exemplo, em um sistema de precificação, políticas diferentes podem ser aplicadas para determinar descontos ou ajustes de preços, resultando em valores numéricos ou outras saídas complexas.
3. Seleção de Comportamentos ou Ações:
   O padrão também pode determinar quais comportamentos ou ações devem ser executados. Em um sistema de processamento de pedidos, diferentes políticas podem decidir o método de envio, a estratégia de priorização ou o fluxo de trabalho a ser seguido, dependendo das condições.
4. Composição de Resultados:
   O Policy Pattern permite a combinação de várias políticas para determinar um resultado composto. Por exemplo, um sistema de roteamento de mensagens pode aplicar várias políticas para decidir a rota ideal, o tempo de envio e as condições de fallback.

O Policy Pattern é versátil e pode ser aplicado para mais do que simples respostas binárias. Ele pode ser utilizado para determinar regras complexas, calcular valores, selecionar comportamentos e compor decisões baseadas em múltiplas políticas. Isso o torna uma ferramenta poderosa para gerenciar a lógica de negócios em sistemas que exigem flexibilidade e adaptabilidade.

Diferenças e Similaridades entre Policy e Strategy

Similaridades:

1. Encapsulamento de Comportamentos:
   Tanto o Policy Pattern quanto o Strategy Pattern encapsulam comportamentos ou regras em classes separadas, permitindo que esses comportamentos sejam intercambiáveis sem alterar o código cliente. Ambos os padrões promovem a flexibilidade e a modularidade do sistema, facilitando a substituição e a extensão dos algoritmos ou regras.
2. Interface Comum:
   Ambos os padrões usam interfaces ou classes abstratas para definir um contrato comum que deve ser seguido pelas implementações concretas. Isso permite que o código que utiliza essas estratégias ou políticas trabalhe com elas de maneira uniforme e desacoplada da implementação específica.

Diferenças:

Foco e Aplicação:

• Strategy Pattern: O Strategy Pattern é mais focado na seleção e execução de algoritmos ou procedimentos que podem variar. Ele é amplamente utilizado quando diferentes abordagens para resolver um problema específico são necessárias, como diferentes métodos de ordenação, compressão, ou algoritmos de busca.
• Policy Pattern: O Policy Pattern, por outro lado, é voltado para a definição e aplicação de regras de negócio ou diretrizes operacionais. Ele é mais comumente utilizado para gerenciar condições ou regras que podem governar o comportamento de um sistema, como regras de autorização, cálculo de tarifas, ou validações.

Natureza da Decisão:

• Strategy Pattern: A seleção de uma estratégia no Strategy Pattern é normalmente determinada em tempo de execução com base em algum critério, mas a estratégia em si é uma implementação completa e única de um algoritmo. O foco é mais em “como” um comportamento é realizado.
• Policy Pattern: O Policy Pattern é mais sobre “o que” deve ser permitido ou aplicado de acordo com regras específicas. Ele pode determinar não apenas um único comportamento, mas também combinar várias políticas para chegar a uma decisão final.

Quando Usar um ou Outro:

Use Strategy Pattern Quando:

• Você tem várias maneiras de realizar uma tarefa específica, e precisa selecionar uma delas em tempo de execução.
• O objetivo é escolher entre diferentes algoritmos que resolvem o mesmo problema, mas com diferentes trade-offs (como eficiência ou precisão).
• Você quer evitar condicionais complexas (if-else ou switch) dentro de um método.

Use Policy Pattern Quando:

• Você precisa aplicar regras de negócio ou políticas que podem variar ou ser combinadas para determinar um comportamento.
• O sistema requer flexibilidade na aplicação de diretrizes, como diferentes regras de autorização, validações, ou políticas de cálculo.
• As regras podem ser adicionadas, removidas ou combinadas sem necessidade de alterar o código principal.

Quando Usá-los de Forma Combinada:

Os padrões Policy e Strategy podem ser usados em conjunto quando você precisa selecionar e aplicar algoritmos que são governados por regras de negócio:

• Exemplo Combinado: Suponha que você esteja desenvolvendo um sistema de processamento de transações financeiras. O Strategy Pattern poderia ser utilizado para escolher entre diferentes algoritmos de processamento de transações (como métodos de pagamento ou criptografia). Ao mesmo tempo, o Policy Pattern poderia ser aplicado para definir regras que determinam quais estratégias podem ser usadas, como restrições baseadas na localização, no valor da transação ou no tipo de cliente.
• Cenário de Uso Combinado: Você poderia combinar políticas de segurança (Policy) para decidir se uma determinada transação deve ser processada e, em seguida, selecionar o algoritmo de processamento (Strategy) apropriado para executar essa transação.

Diferenças e Similaridades entre Policy e Specification

Similaridades:

Tanto o Policy Pattern quanto o Specification Pattern encapsulam lógica ou regras em classes separadas, promovendo modularidade e flexibilidade. Ambos permitem que diferentes regras ou critérios sejam definidos e aplicados de maneira intercambiável, facilitando a adaptação do sistema a novos requisitos sem grandes modificações no código.

Além disso, ambos os padrões utilizam interfaces ou classes abstratas para definir um contrato comum que deve ser seguido pelas implementações concretas. Isso garante que o código cliente possa interagir com essas políticas ou especificações sem depender das implementações específicas, mantendo o sistema desacoplado e fácil de manter.

Diferenças:

O Policy Pattern se concentra na aplicação de regras de negócio ou diretrizes que governam o comportamento de um sistema, definindo “o que” deve ser permitido ou decidido em contextos específicos. Ele é usado para determinar ações, permissões ou parâmetros com base em regras que podem ser combinadas ou alteradas dinamicamente.

Por outro lado, o Specification Pattern é focado na definição de critérios ou condições que um objeto deve atender. Ele é particularmente útil para validar, filtrar ou consultar objetos, verificando se eles cumprem determinadas condições. Enquanto o Policy pode lidar com decisões complexas, o Specification geralmente avalia se um objeto cumpre ou não uma condição específica.

Quando Usar:

Use o Policy Pattern quando precisar aplicar regras de negócio que governam o comportamento do sistema, como políticas de segurança, autorização ou cálculos de preços. Esse padrão é ideal em situações onde as regras precisam ser dinâmicas, podendo ser combinadas ou ajustadas para decidir como o sistema deve se comportar em diferentes contextos.

O Specification Pattern é mais apropriado quando você precisa verificar se objetos atendem a critérios específicos, como em validações, filtragens ou consultas. Ele é especialmente útil quando as condições são complexas e precisam ser compostas usando operações lógicas, como em sistemas que exigem a combinação de múltiplos critérios para determinar a adequação de um objeto.

Quando Utilizá-los de Forma Combinada:

Os padrões Policy e Specification podem ser combinados em cenários onde é necessário aplicar regras de negócio a objetos que devem cumprir certas condições. Por exemplo, em um sistema de e-commerce, você pode usar Specification para verificar se um produto está dentro de uma faixa de preço e tem estoque disponível, enquanto o Policy Pattern aplica regras de desconto ou frete grátis, determinando o preço final ou as condições de envio.

Conclusão

Enquanto o Policy Pattern é voltado para a aplicação de regras de negócio dinâmicas que influenciam o comportamento do sistema, o Specification Pattern é ideal para verificar se objetos atendem a condições específicas. Combinados, esses padrões oferecem uma abordagem poderosa para gerenciar regras e condições em sistemas complexos, permitindo flexibilidade e clareza na definição de comportamentos e critérios.

Exemplos Práticos

1. Sistemas de Autenticação: Em um sistema que controla o acesso de usuários, o Policy Pattern pode ser usado para definir políticas de autenticação como autenticação de dois fatores, políticas de expiração de senhas e políticas de acesso baseadas em função.
2. Cálculo de Tarifas: Em um sistema de gestão de tarifas, diferentes políticas podem ser aplicadas para calcular preços com base em fatores como horário, localização ou tipo de cliente. Por exemplo, uma política de descontos para clientes VIP pode ser aplicada em conjunto com uma política de preço dinâmico baseada na demanda.

Analogias e Metáforas

O Policy Pattern pode ser comparado a um conjunto de regras de um jogo de tabuleiro. Assim como diferentes regras podem ser aplicadas para criar variações do mesmo jogo, o Policy Pattern permite que diferentes políticas sejam combinadas e aplicadas para controlar como um sistema opera em diferentes situações.

Importância

O Policy Pattern é importante porque oferece uma maneira organizada de lidar com regras de negócio que podem ser complexas e sujeitas a mudanças frequentes. Ao encapsular políticas em classes separadas, o padrão facilita a manutenção e a extensão do sistema, permitindo que novas políticas sejam adicionadas ou alteradas sem impactar o restante do código.

Limitações e Críticas

Uma das limitações do Policy Pattern é que ele pode introduzir complexidade adicional ao sistema, especialmente se houver um grande número de políticas que precisam ser gerenciadas. Além disso, se as políticas forem muito interdependentes, o desacoplamento pode se tornar difícil, comprometendo a clareza e a simplicidade do design.

Comparação com conceitos similares

• Strategy Pattern: Ambos os padrões encapsulam comportamentos, mas o Policy Pattern é mais voltado para a aplicação de regras de negócio, enquanto o Strategy Pattern foca na seleção de algoritmos. No Strategy, as estratégias são frequentemente mutuamente exclusivas, enquanto no Policy, as políticas podem ser combinadas.
• Rules Engine: Um Rules Engine permite a definição e o gerenciamento de regras de negócio de forma declarativa, enquanto o Policy Pattern organiza essas regras em uma estrutura mais orientada a objetos. Um Rules Engine pode ser considerado uma implementação mais complexa e geral do conceito de políticas.

Perguntas Frequentes (FAQs)

O Policy Pattern pode ser aplicado em sistemas com políticas muito complexas?
Sim, mas é importante considerar a complexidade adicional que isso pode introduzir. Em sistemas muito complexos, o uso de um Rules Engine pode ser mais apropriado.

Como o Policy Pattern melhora a manutenção do código?
Ele melhora a manutenção ao encapsular as políticas em classes separadas, permitindo que novas regras sejam adicionadas ou alteradas sem modificar o restante do código.

O Policy Pattern é adequado para sistemas pequenos?
Depende. Em sistemas pequenos, a implementação do Policy Pattern pode ser desnecessária se as regras de negócio forem simples e não mudarem frequentemente.

Recursos Adicionais

• “Design Patterns: Elements of Reusable Object-Oriented Software” por Erich Gamma, Richard Helm, Ralph Johnson, e John Vlissides (Gang of Four).
• “Domain-Driven Design: Tackling Complexity in the Heart of Software” por Eric Evans.
• “Patterns of Enterprise Application Architecture” por Martin Fowler.