Padrões pythônicos e código limpo

Padrão estratégia com uma função

Em muitas linguagens, escolher um algoritmo em tempo de execução exige o padrão estratégia com várias classes: uma interface e uma classe para cada variação. Em Python, isso costuma ser exagero, porque funções são objetos de primeira classe: você pode guardar uma função numa variável, colocá-la num dicionário e passá-la como argumento. O padrão estratégia então se resume a escolher qual função usar. O resultado é um código muito mais enxuto, que faz o mesmo trabalho sem a cerimônia de uma hierarquia de classes.

def frete_normal(peso: float) -> float:
    return peso * 2.0

def frete_expresso(peso: float) -> float:
    return peso * 2.0 + 15.0

def frete_gratis(peso: float) -> float:
    return 0.0

# A "estrategia" e apenas a funcao escolhida
def calcular_frete(peso: float, estrategia) -> float:
    return estrategia(peso)

print(calcular_frete(10, frete_expresso))   # 35.0

# Um dicionario mapeia nome para estrategia, sem cadeia de if
estrategias = {"normal": frete_normal, "expresso": frete_expresso, "gratis": frete_gratis}
escolha = "gratis"
print(calcular_frete(10, estrategias[escolha]))   # 0.0

O padrão estratégia em Python: passar a função e mapear nomes para funções num dicionário.

O dicionário de estratégias merece atenção, porque substitui com elegância uma cadeia de if e elif. Em vez de comparar o nome da escolha num monte de condicionais, você mapeia cada nome para a função correspondente e busca direto. Adicionar uma estratégia nova é acrescentar uma entrada no dicionário, sem tocar na função calcular_frete. É o princípio aberto-fechado da aula anterior aparecendo de novo, agora no estilo enxuto e funcional que o Python favorece.

Uma fábrica simples

Outro padrão clássico que fica leve em Python é a fábrica, uma função cujo trabalho é criar e devolver o objeto certo conforme a entrada, escondendo de quem chama os detalhes de qual classe instanciar. Ela centraliza a decisão de criação num só lugar. Se amanhã surgir um tipo novo, você mexe apenas na fábrica, e todo o resto do código, que só pede um objeto à fábrica, continua igual. É uma aplicação direta de responsabilidade única, com a criação isolada do uso.

from abc import ABC, abstractmethod

class Notificador(ABC):
    @abstractmethod
    def enviar(self, mensagem: str) -> None: ...

class NotificadorEmail(Notificador):
    def enviar(self, mensagem: str) -> None:
        print(f"e-mail: {mensagem}")

class NotificadorSMS(Notificador):
    def enviar(self, mensagem: str) -> None:
        print(f"sms: {mensagem}")

# Fabrica: decide qual objeto criar; quem chama nao precisa saber
def criar_notificador(canal: str) -> Notificador:
    tipos = {"email": NotificadorEmail, "sms": NotificadorSMS}
    if canal not in tipos:
        raise ValueError(f"canal desconhecido: {canal}")
    return tipos[canal]()

n = criar_notificador("sms")
n.enviar("seu pedido foi enviado")   # sms: seu pedido foi enviado

A fábrica criar_notificador concentra a decisão de qual classe instanciar num único lugar.

Código limpo: o alicerce de tudo

Nenhum padrão salva um código de nomes ruins e funções gigantes. O código limpo é o alicerce, e ele começa nos nomes. Um nome deve dizer o que a coisa é ou faz, sem exigir um comentário: calcular_frete é melhor que cf, quantidade_itens é melhor que qi. Em seguida vêm as funções pequenas, que fazem uma coisa só e cabem na tela; quando uma função cresce demais e ganha vários blocos com comentários explicando cada trecho, é sinal de que ela quer virar várias funções. Código limpo não é enfeite; é o que permite ler, entender e mudar sem medo.

O terceiro pilar é o princípio DRY, não se repita. Quando a mesma lógica aparece copiada em três lugares, uma correção precisa ser feita três vezes, e um dia você esquece uma delas: nasce o bug. Extraia a lógica repetida para uma função com um bom nome e chame-a nos três lugares. Agora a mudança acontece num ponto só. Um cuidado honesto: DRY é sobre não duplicar conhecimento, não sobre eliminar toda linha parecida a qualquer custo. Forçar a fusão de trechos que só por acaso se parecem cria acoplamento ruim. O bom senso, como sempre, decide.

Com este módulo você fecha o lado de engenharia do curso. Já sabe estruturar um projeto em pacotes, declará-lo no pyproject.toml, resolver imports, manter o estilo com PEP 8 e ferramentas, aplicar os princípios de SOLID com moderação e escrever código limpo e pythônico. É exatamente esse conjunto que separa quem faz scripts que funcionam de quem constrói software que uma equipe mantém por anos. No próximo e último módulo, tudo isso vira prática: você projeta e constrói uma mini biblioteca completa.