Riverfount

Um espaço para meus devaneios, sejam em TI ou em Filosofia

Você já enfrentou resultados inesperados ao usar listas ou dicionários como valores padrão em funções Python? Esse é um problema comum que pode causar bugs sutis e difíceis de encontrar. Neste artigo técnico, vamos desmistificar o motivo desse comportamento, mostrando exemplos práticos e como evitá-lo com boas práticas de programação. Se você é um desenvolvedor Python buscando produzir código mais robusto e previsível, este conteúdo é essencial para o seu dia a dia.

Evitando Surpresas

Ao definir funções em Python, usar valores padrão em argumentos é comum para facilitar chamadas. Contudo, quando o valor padrão é um tipo mutável, como listas ou dicionários, isso pode causar efeitos inesperados. Vamos analisar exemplos para entender esse comportamento.

Exemplo Problemático: Lista Mutável como Valor Padrão

def add_item(item, lista=[]):
    lista.append(item)
    return lista

print(add_item('maçã'))    # Saída esperada: ['maçã']
print(add_item('banana'))  # Saída inesperada: ['maçã', 'banana']

Aqui, o segundo print adiciona o item 'banana' à mesma lista usada na primeira chamada, porque o objeto lista padrão foi criado uma vez e reutilizado. Isso acontece porque argumentos padrão são avaliados apenas na definição da função.

Corrigindo com None como Valor Padrão

A forma recomendada é usar None e criar a lista dentro da função quando necessário:

def add_item(item, lista=None):
    if lista is None:
        lista = []
    lista.append(item)
    return lista

print(add_item('maçã'))    # Saída: ['maçã']
print(add_item('banana'))  # Saída: ['banana']

Assim, cada chamada sem lista passa a criar uma nova lista vazia, evitando efeitos colaterais.

Mais um Exemplo com Dicionário Mutável

def increment_count(key, counts={}):
    counts[key] = counts.get(key, 0) + 1
    return counts

print(increment_count('python'))  # {'python': 1}
print(increment_count('java'))    # {'python': 1, 'java': 1} – resultado inesperado

No caso acima, o dicionário padrão é compartilhado e mantido entre as chamadas. A forma correta:

def increment_count(key, counts=None):
    if counts is None:
        counts = {}
    counts[key] = counts.get(key, 0) + 1
    return counts

print(increment_count('python'))  # {'python': 1}
print(increment_count('java'))    # {'java': 1}

Exemplo com Classe e Argumento Mutável

class Collector:
    def __init__(self, items=[]):
        self.items = items

    def add(self, item):
        self.items.append(item)

    def get_items(self):
        return self.items

c1 = Collector()
c1.add('foo')

c2 = Collector()
print(c2.get_items())  # Saída inesperada: ['foo']

A mesma lista é compartilhada por todas as instâncias quando passada como valor padrão mutável. Correção:

class Collector:
    def __init__(self, items=None):
        self.items = items or []

    def add(self, item):
        self.items.append(item)

    def get_items(self):
        return self.items

c1 = Collector()
c1.add('foo')

c2 = Collector()
print(c2.get_items())  # Saída correta: []

Boas Práticas para Evitar Problemas com Argumentos Mutáveis

  • Nunca use tipos mutáveis como valores padrão de argumentos. Prefira usar None e inicialize a variável dentro da função.

  • Evite efeitos colaterais em funções. Funções devem ser previsíveis e sempre retornar resultados baseados em seus argumentos.

  • Prefira tipos imutáveis para valores padrão. Imutáveis como int, str e tuple não causam esse tipo de problema.

  • Ao lidar com objetos mutáveis, clone-os quando necessário. Use métodos como copy() ou slicing para evitar alterações inesperadas.

  • Teste cuidadosamente funções que recebem parâmetros opcionais. Garanta que o estado de chamadas anteriores não afete as subsequentes.

  • Documente o comportamento esperado de seus métodos, especialmente em bibliotecas e APIs. Indique claramente se objetos mutáveis são compartilhados ou não.

Dominar essas técnicas ajuda a produzir código Python mais resiliente e menos propenso a bugs difíceis de detectar, essencial para engenheiros de software que buscam qualidade profissional em seus projetos.



Riverfount
Vicente Eduardo Ribeiro Marçal

Entenda os riscos do uso de from módulo import * em Python, saiba por que ele compromete a legibilidade e a manutenção do código e descubra as alternativas recomendadas por desenvolvedores experientes.

A armadilha da conveniência em Python

Há algo em Python que seduz até os desenvolvedores mais experientes: a promessa de simplicidade. Poucas linguagens conseguem equilibrar legibilidade e poder expressivo como ele faz. Mas é justamente essa aparente simplicidade que, às vezes, nos leva a atalhos perigosos. Entre eles, um velho conhecido: from módulo import *.

Essa linha, tão curta quanto tentadora, parece inofensiva em pequenos scripts… até que o projeto cresce, outros módulos entram em cena e o caos começa a se insinuar. O que parecia elegante se transforma em um labirinto de dependências invisíveis, nomes sobrescritos e bugs indecifráveis.

A falsa sensação de simplicidade

Importar tudo de um módulo é como abrir as portas da sua casa e deixar qualquer um entrar. De início, parece acolhedor. Mas quando algo dá errado, você não sabe quem fez a bagunça. Essa é a essência do problema: o código perde fronteiras claras.

Quando um projeto cresce, inevitavelmente surgem conflitos de nome. Uma função sua pode ter o mesmo nome de algo importado, e lá se vai a previsibilidade do comportamento do código. E o pior: o erro nem sempre se manifesta de forma imediata — ele se infiltra sutilmente, como um bug fantasma que só aparece na pior hora possível.

Legibilidade acima da brevidade

Um código é tão bom quanto sua capacidade de ser compreendido por outras pessoas (inclusive você no futuro). Ao usar import *, você apaga pistas valiosas sobre de onde vêm as funções que usa. Quando um leitor se depara com sqrt(16), ele precisa adivinhar: é uma função da biblioteca padrão, algo definido localmente ou algo importado de um módulo obscuro?

Essa incerteza sabota um princípio essencial de engenharia: previsibilidade. Códigos que exigem adivinhações são códigos menos confiáveis.

Custo oculto e impacto no código

O uso de from módulo import * não implica em maior custo de desempenho ou tempo de carregamento. Ao importar um módulo, o interpretador Python o carrega e inicializa apenas uma vez, armazenando-o em sys.modules. As importações subsequentes, com ou sem *, apenas criam novas referências aos objetos já existentes.

O verdadeiro impacto está na legibilidade e manutenção. A importação global adiciona múltiplos nomes ao namespace atual, podendo sobrescrever identificadores e dificultar a rastreabilidade das dependências. Isso reduz a previsibilidade do código e aumenta o risco de colisões de nomes e efeitos colaterais sutis, principalmente em bases de código extensas.

Em projetos de médio e grande porte, recomenda-se sempre preferir importações explícitas (import módulo ou from módulo import símbolo) para preservar a clareza e facilitar ferramentas de análise estática, refatoração e autocompletar em IDEs.

Alternativas seguras e idiomáticas em Python

A boa notícia é que a linguagem oferece opções mais claras — e alinhadas com a filosofia “Explicit is better than implicit”:

from math import sqrt, pi

Importe apenas o que você precisa e comunique intenção.

Ou, se preferir manter a origem explícita:

import math
resultado = math.sqrt(16)

A notação com ponto reforça a origem de cada função.

E em casos de bibliotecas extensas, os alias ajudam:

import pandas as pd
df = pd.read_csv("data.csv")

Essa convenção é legível, padronizada e amplamente aceita pela comunidade.

Um sinal de maturidade profissional

Código limpo não é o mais curto, e sim o mais claro. Evitar import * é um passo em direção à maturidade profissional. É escolher clareza e previsibilidade no lugar da pressa.

Em tempos em que a maioria dos bugs surge nas fronteiras entre módulos, saber exatamente de onde cada símbolo vem não é luxo — é controle.

Um convite à reflexão

Na próxima vez que você digitar from módulo import *, pause. Pergunte-se se a conveniência justifica o custo. O Python recompensa quem escolhe caminhos explícitos. E talvez o maior sinal de evolução como engenheiro Python seja perceber que clareza é o verdadeiro atalho.

🧭 Boas práticas resumidas

  • Prefira importações explícitas (from math import sqrt, pi).
  • Use alias padronizados em bibliotecas populares (import pandas as pd, import numpy as np).
  • Evite nomes genéricos que possam colidir com funções de módulos.
  • Documente qualquer alias ou importação incomum no projeto.
  • Faça revisões periódicas no código para eliminar usos antigos de import *.
  • Valorize a clareza: código previsível é sinônimo de código profissional.



Riverfount
Vicente Eduardo Ribeiro Marçal

No desenvolvimento Python, especialmente em projetos de médio a grande porte e pipelines complexos de testes automatizados, é comum encontrar erros sutis relacionados a comparações com o valor booleano True. Uma prática aparentemente inofensiva, como usar == True para verificar condições, pode introduzir comportamentos inesperados que dificultam a manutenção, geram falsos positivos em testes e causam dúvidas em revisões de código.

Essas situações não são incomuns em equipes que lidam com múltiplas camadas de abstração — desde o código de negócio até frameworks de teste — e evidenciam a importância de entender profundamente a diferença entre identidade e igualdade em Python, bem como as melhores práticas para escrever condicionais claras e robustas.

Entendendo o impacto de is True vs == True

O operador is verifica se dois objetos são exatamente os mesmos na memória — ou seja, se têm identidade. No caso de var is True, o teste passa somente se var for exatamente o objeto singleton True do Python.

Já o operador == compara valores, permitindo que diversos objetos considerados “truthy” no contexto booleano, como 1, Strings não vazias ou listas, sejam equivalentes a True quando comparados com var == True. Isso pode causar falhas silenciosas ou testes que passam indevidamente.

if 1 == True:  # Avalia para True, embora 1 não seja o objeto True
    print("Isso pode confundir a lógica.")

Esse tipo de resultado pode mascarar bugs ou comportamentos inesperados, especialmente em testes unitários.

Evitando comparações explícitas desnecessárias

O consenso na comunidade Python — refletido em PEP8 e amplamente adotado — é que a maioria das comparações explícitas com True e False são redundantes e prejudicam a legibilidade. Python permite confiar diretamente na avaliação booleana implícita, que é mais limpa e expressiva.

# Menos legível
if var == True:
    ...

# Idiomático
if var:
    ...

# Para casos False
if not var:
    ...

Essa abordagem reduz o ruído visual e elimina ambiguidades causadas por diferentes tipos que avaliam para verdadeiro ou falso.

Exemplos práticos de erros comuns

  • Erro em comparações com listas booleanas:
a = [True, True, False]
b = [True, True, True]

result = a and b  
print(result)  # Saída: [True, True, True]

Aqui, usar and entre listas não faz uma comparação elemento a elemento, mas retorna o último valor avaliado. Isso pode levar a resultados inesperados, especialmente se se esperava um valor booleano.

  • Confusão com tipos de retornos em bibliotecas como NumPy:

Em NumPy, comparações booleanas não retornam True ou False do Python nativo, mas tipos como np.True_ ou np.False_, que podem quebrar testes que usam is True:

import numpy as np

result = np.array([1, 2, 3]) == 1
print(result)          # array([ True, False, False])
print(result[0] is True)  # False, pois é np.bool_, não bool nativo

Essa sutileza é fonte comum de bugs em projetos científicos e de análise de dados.

  • Falsos positivos em testes unitários:
def test_func():
    result = 1
    assert result == True  # Passa, mas result não é booleano

    assert result is True  # Falha, aqui a precisão salva o teste

O uso de is True impede que valores “truthy” como 1 passem em testes que esperam tipos booleanos.

Casos excepcionais: validação rigorosa em testes unitários

Há, todavia, situações específicas — especialmente em testes unitários — onde a precisão semântica é necessária. Quando uma função ou método deve retornar explicitamente o valor booleano True, e não apenas um “valor truthy” qualquer, o uso de assert ... is True garante que o teste falhe se houver qualquer discrepância de tipo ou valor.

def is_even(number):
    return number % 2 == 0

def test_is_even():
    result = is_even(4)

    # Verificação rigorosa: valida identidade
    assert result is True

    # Evitar
    assert result == True

Essa prática ajuda a prevenir falsos positivos em pipelines de CI/CD, assegurando que o comportamento funcional esperado esteja alinhado com tipos e valores corretos e não somente com avaliações booleanas superficiais.

Conclusão: clareza e rigor em equilíbrio

Escrever código Python robusto é também dominar as sutilezas da linguagem. Evitar comparações explícitas desnecessárias com True não só melhora a clareza, como também reduz riscos de bugs ocultos.

Por outro lado, saber quando estabelecer verificações estritas, como em testes unitários com is True, demonstra maturidade técnica e compromisso com a qualidade.

Equilibrar legibilidade e precisão é o passo decisivo que diferencia código “funcional” de código profissional, limpo e confiável.



Riverfount
Vicente Eduardo Ribeiro Marçal

Resumo:
O Princípio da Inversão de Dependência (DIP), parte do conjunto SOLID, é fundamental para criar sistemas sustentáveis, extensíveis e fáceis de testar. Este artigo explora como aplicá-lo em Python usando typing.Protocol e injeção de dependência, com foco em arquiteturas limpas e aplicação prática em sistemas corporativos.

Contexto

Projetos orientados a objetos de longo prazo exigem mais do que modularidade: precisam de estabilidade arquitetural. O Princípio da Inversão de Dependência (Dependency Inversion Principle – DIP) aborda exatamente esse ponto.
Ele recomenda que módulos de alto nível (os que contêm as regras de negócio) não conheçam os detalhes de baixo nível (implementações, drivers, frameworks), mas interajam por meio de abstrações.

Mesmo em uma linguagem dinâmica como Python, onde acoplamentos podem parecer menos problemáticos, o DIP se torna essencial em sistemas corporativos com múltiplos serviços e integrações externas, garantindo desacoplamento e testabilidade.

O problema: quando o código depende de detalhes

Imagine um serviço que envia notificações a usuários. Uma implementação comum é instanciar dependências diretamente dentro da classe de negócio:

class EmailService:
    def send_email(self, to: str, message: str) -> None:
        print(f"Enviando e-mail para {to}: {message}")


class UserNotifier:
    def __init__(self) -> None:
        self.email_service = EmailService()  # dependência concreta

    def notify_user(self, user_email: str, msg: str) -> None:
        self.email_service.send_email(user_email, msg)

Embora funcional, essa abordagem cria acoplamento rígido. Qualquer mudança no método de envio (ex.: SMS, Push, Webhook) exige alterar UserNotifier, o que viola diretamente o DIP e propaga dependências desnecessárias.

A solução: abstrações com Protocols

O DIP recomenda inverter essa dependência — o módulo de alto nível deve depender de uma abstração, e não de um detalhe concreto.
Desde o Python 3.8, a PEP 544 introduziu typing.Protocol, permitindo descrever contratos de interface de modo estático e seguro.

from typing import Protocol


class Notifier(Protocol):
    def send(self, to: str, message: str) -> None:
        ...

A partir do contrato, diferentes mecanismos podem ser implementados:

class EmailNotifier:
    def send(self, to: str, message: str) -> None:
        print(f"Email para {to}: {message}")


class SMSNotifier:
    def send(self, to: str, message: str) -> None:
        print(f"SMS enviado para {to}: {message}")

Assim, o módulo de negócio depende apenas de uma abstração genérica:

class UserNotifier:
    def __init__(self, notifier: Notifier) -> None:
        self._notifier = notifier

    def notify(self, user_email: str, msg: str) -> None:
        self._notifier.send(user_email, msg)

O uso torna-se desacoplado e configurável:

email_notifier = EmailNotifier()
user_notifier = UserNotifier(email_notifier)
user_notifier.notify("joao@example.com", "Bem-vindo ao sistema!")

sms_notifier = SMSNotifier()
user_notifier = UserNotifier(sms_notifier)
user_notifier.notify("+5511999999999", "Código de autenticação: 123456")

Benefícios e impacto arquitetural

A aplicação do DIP resulta em ganhos tangíveis de engenharia:

  • Desacoplamento estrutural: classes de domínio não conhecem implementações concretas.
  • Extensibilidade controlada: adicionar novos canais ou comportamentos não requer refatoração de código existente.
  • Testabilidade facilitada: dependências podem ser simuladas ou injetadas em testes unitários.
  • Conformidade com arquiteturas limpas: o domínio permanece independente da infraestrutura.

Em projetos complexos, contêineres de injeção como dependency-injector ou punq podem automatizar a resolução de dependências sem comprometer a clareza arquitetural.

Boas práticas e armadilhas comuns

Boas práticas

  • Defina contratos explícitos: sempre que um módulo precisar interagir com outro de baixo nível, defina um Protocol.
  • Mantenha o domínio puro: o código de negócio deve ser independente de frameworks e bibliotecas externas.
  • Use tipagem estática: ferramentas como mypy ajudam a validar conformidade de implementações com Protocols.
  • Aplique injeção de dependência: crie instâncias fora do domínio e injete-as no construtor (ou em fábricas específicas).

Armadilhas frequentes

  • Overengineering: evite criar abstrações desnecessárias. Se há apenas uma implementação e não há expectativa de variação, o custo de manter o contrato pode não compensar.
  • Dependência indireta: trocar dependência direta por uma indireta mal desenhada (por exemplo, uma abstração genérica demais) reduz a clareza do sistema.
  • Confusão entre abstração e herança: Protocols substituem interfaces, não exigem herança e não impõem rigidez hierárquica.

Adotar o DIP não significa adicionar camadas de complexidade artificial, mas desenhar fronteiras claras entre políticas e detalhes técnicos.

Conclusão

O Princípio da Inversão de Dependência é mais do que uma regra teórica do SOLID: é uma mentalidade de design voltada à estabilidade e evolução contínua.
Em Python, o uso de Protocol e injeção de dependência permite aplicar o DIP de forma idiomática, preservando a simplicidade da linguagem sem abrir mão da qualidade arquitetural.
Em sistemas que precisam evoluir com segurança, o DIP é uma das práticas mais valiosas — e um dos marcos de maturidade de um engenheiro de software sênior.



Riverfount
Vicente Eduardo Ribeiro Marçal

O Princípio da Segregação de Interfaces (ISP — Interface Segregation Principle) é um dos pilares do SOLID e trata diretamente da qualidade dos contratos entre componentes. Em essência, ele afirma que uma classe não deve ser obrigada a depender de métodos que não utiliza. Essa regra incentiva o desenho de interfaces menores, mais coesas e representativas de um papel específico no sistema.

Na prática, o ISP força uma reflexão arquitetural: qual é a verdadeira responsabilidade dessa abstração? Se a resposta envolve comportamentos heterogêneos, a interface provavelmente está concentrando demasiadas responsabilidades — um sinal de design frágil e baixo reuso.

O problema das interfaces genéricas

Considere um caso comum: um módulo que define uma interface genérica de “dispositivo multifuncional”. Ela impõe à hierarquia de classes um contrato extenso, mesmo que nem todas as implementações precisem de todas as operações.

from abc import ABC, abstractmethod

class MultiFunctionDevice(ABC):
    @abstractmethod
    def print_document(self, document): pass

    @abstractmethod
    def scan_document(self, document): pass

    @abstractmethod
    def fax_document(self, document): pass


class BasicPrinter(MultiFunctionDevice):
    def print_document(self, document):
        print(f"Imprimindo: {document}")

    def scan_document(self, document):
        raise NotImplementedError("Este dispositivo não suporta digitalização")

    def fax_document(self, document):
        raise NotImplementedError("Este dispositivo não envia fax")

Aqui, BasicPrinter viola o ISP porque é forçada a implementar métodos irrelevantes. Qualquer alteração em MultiFunctionDevice pode afetar classes que não deveriam ter relação entre si.

Refinando o design com interfaces específicas

Para evitar esse problema, segmentamos as interfaces em abstrações menores e mais focadas:

from abc import ABC, abstractmethod

class Printable(ABC):
    @abstractmethod
    def print_document(self, document): pass

class Scannable(ABC):
    @abstractmethod
    def scan_document(self, document): pass

class Faxable(ABC):
    @abstractmethod
    def fax_document(self, document): pass


class BasicPrinter(Printable):
    def print_document(self, document):
        print(f"Imprimindo: {document}")


class MultiFunctionPrinter(Printable, Scannable, Faxable):
    def print_document(self, document):
        print(f"Imprimindo: {document}")

    def scan_document(self, document):
        print(f"Digitalizando: {document}")

    def fax_document(self, document):
        print(f"Enviando fax: {document}")

Cada interface é coesa e independente. As classes agora implementam apenas as operações relevantes às suas funcionalidades, reduzindo o acoplamento e melhorando a clareza estrutural.

Abordagem moderna com typing.Protocol

A partir do Python 3.8, typing.Protocol permite expressar contratos comportamentais baseados em tipagem estrutural (também chamada de duck typing verificado estaticamente). Esse recurso é especialmente compatível com o ISP, pois elimina a necessidade de herança explícita para validar conformidade de tipo.

from typing import Protocol

class Printable(Protocol):
    def print_document(self, document: str) -> None: ...

class Scannable(Protocol):
    def scan_document(self, document: str) -> None: ...


class BasicPrinter:
    def print_document(self, document: str) -> None:
        print(f"Imprimindo: {document}")


class SmartDevice:
    def print_document(self, document: str) -> None:
        print(f"Imprimindo: {document}")

    def scan_document(self, document: str) -> None:
        print(f"Digitalizando: {document}")


def print_any(printer: Printable, content: str) -> None:
    printer.print_document(content)

Observe que BasicPrinter e SmartDevice não herdam explicitamente de Printable ou Scannable, mas o type checker reconhecerá ambas as classes como compatíveis por possuírem os métodos exigidos. Essa abordagem é vantajosa porque:

  • Mantém baixo acoplamento entre tipos, reforçando a aplicação do ISP.
  • Usa duck typing com suporte de tipagem estática (útil em ferramentas como mypy).
  • Favorece design evolutivo; novos comportamentos podem ser adicionados a outras classes sem quebrar a hierarquia.

Assim, Protocol é a forma moderna e idiomática de aplicar o ISP em projetos Python, tornando clara a separação de responsabilidades e preservando a flexibilidade da linguagem.

Conclusão

O ISP é mais que um princípio de design: é uma diretriz para compor sistemas orientados a abstrações coesas e independentes. No ecossistema Python, a evolução da tipagem com abc e Protocol oferece duas formas complementares de expressar esse princípio — uma baseada em herança nominal, outra em compatibilidade estrutural.

Projetar interfaces enxutas e especializadas é um ato de disciplina arquitetural: reduz o impacto de mudanças, aumenta a clareza e favorece a manutenibilidade a longo prazo. Em times maduros, a aplicação do ISP reflete um domínio avançado de separação de responsabilidades e uma compreensão profunda da dinâmica entre contrato e implementação.



Riverfount
Vicente Eduardo Ribeiro Marçal

No mundo da programação orientada a objetos, o Princípio de Substituição de Liskov (LSP) é um guia essencial para criar sistemas robustos e flexíveis. Porém, em Python, esse princípio ganha uma nuance especial graças ao duck typing e aos protocolos, que mudam completamente a forma como pensamos em substituição e hierarquia.

Neste post, vamos explorar como esses conceitos se entrelaçam, por que o LSP faz tanto sentido na linguagem pythonica e como seu entendimento ajuda a escrever códigos mais limpos, seguros e reutilizáveis — tudo isso sem depender exclusivamente de herança formal. Prepare-se para olhar para o LSP através das lentes de Python e descobrir ferramentas poderosas para o design de software elegante e eficiente.

LSP e Duck Typing: O Poder do Comportamento

Em linguagens estaticamente tipadas, o LSP está intimamente ligado à hierarquia de classes e à herança formal. Já em Python, graças ao duck typing, não é a herança que define a possibilidade de substituição, mas o comportamento do objeto. Se um objeto “grasna” e “anda” como um pato, ele pode ser tratado como um pato, independentemente de sua árvore de classes.

Exemplo simples:

class PatoReal:
    def voar(self):
        print("Voando!")

    def grasnar(self):
        print("Quack!")

class PatoDeBorracha:
    def voar(self):
        raise NotImplementedError("Não posso voar")

    def grasnar(self):
        print("Squeak!")

def fazer_o_pato_grasnar(pato):
    pato.grasnar()

pato_real = PatoReal()
pato_borracha = PatoDeBorracha()

fazer_o_pato_grasnar(pato_real)   # Quack!
fazer_o_pato_grasnar(pato_borracha)  # Squeak!

Aqui, ambos os objetos possuem o método grasnar(), então o código funciona para ambos. No entanto, o método voar() do PatoDeBorracha quebra a expectativa do comportamento esperado, violando o LSP caso o código cliente dependa dele.

Protocolos e o Contrato Explícito

Os protocolos (introduzidos com PEP 544) formalizam essa ideia apresentando um tipo estrutural onde uma “interface” é definida pelo conjunto de métodos que um objeto deve implementar para ser considerado um subtipo daquele protocolo. Diferente da herança tradicional, o protocolo não exige que a classe declare que o implementa explicitamente; ele verifica a compatibilidade estrutural.

Exemplo com protocolo:

from typing import Protocol

class Pato(Protocol):
    def voar(self) -> None:
        ...
    def grasnar(self) -> None:
        ...

class PatoReal:
    def voar(self) -> None:
        print("Voando!")

    def grasnar(self) -> None:
        print("Quack!")

class PatoDeBorracha:
    def voar(self) -> None:
        raise NotImplementedError("Não posso voar")

    def grasnar(self) -> None:
        print("Squeak!")

def fazer_o_pato_voar(pato: Pato) -> None:
    pato.voar()

fazer_o_pato_voar(PatoReal())    # Voando!
fazer_o_pato_voar(PatoDeBorracha())  # Erro: viola LSP

O protocolo Pato define claramente o contrato esperado. Substituir um PatoReal por PatoDeBorracha falha porque PatoDeBorracha não mantém a garantia do método voar.

Interseção do LSP com Duck Typing e Protocolos

  • O LSP reforça que substitutos devem manter o contrato de comportamento original.
  • Duck typing foca na existência desse comportamento ao invés da herança.
  • Protocolos formalizam esse contrato, tornando explícita a interface esperada.
  • Em Python, usar protocolos deixa mais claro onde o LSP pode ser inadvertidamente violado, especialmente em projetos maiores.

Benefícios Práticos

  • Evita exceções inesperadas ou falhas ao substituir objetos que não mantêm o contrato.
  • Permite maior flexibilidade, pois não é necessária herança pura para garantir substituibilidade.
  • Facilita a manutenção e extensibilidade com tipos mais expressivos e contratos claros.
  • Compatibiliza com a filosofia pythonica de código explícito, porém flexível.

Dessa forma, o LSP em Python é mais um guia para respeitar o comportamento esperado, alinhado naturalmente com a dinâmica do duck typing e o rigor dos protocolos, garantindo que seu código seja ao mesmo tempo flexível, seguro e fácil de estender.



Riverfount
Vicente Eduardo Ribeiro Marçal

O Princípio Aberto-Fechado (Open-Closed Principle), um dos pilares do SOLID, é essencial para quem busca escrever código Python orientado a objetos mais flexível, escalável e de fácil manutenção. Ele estabelece que entidades de software — como classes, módulos e funções — devem estar abertas para extensão, mas fechadas para modificação.
Em outras palavras, o comportamento do sistema deve poder evoluir sem necessidade de alterar o código existente.

Entendendo o Princípio Aberto-Fechado

  • Aberto para extensão significa que o sistema pode adquirir novas funcionalidades.
  • Fechado para modificação significa que essas melhorias não devem exigir alterações nas implementações originais, reduzindo a chance de regressões e preservando a integridade do código já testado.

Em Python, a aplicação desse princípio está fortemente relacionada ao uso de abstrações, polimorfismo e injeção de dependências. Projetar para interfaces (ou classes abstratas) é o caminho para permitir evolução sem quebrar funcionalidades existentes.

Exemplo Clássico: Onde o OCP é Quebrado

class Calc:
    def operacao(self, tipo, a, b):
        if tipo == "soma":
            return a + b
        elif tipo == "subtracao":
            return a - b
        # E assim por diante...

Esse design é comum, mas viola o princípio: sempre que surgir uma nova operação, o método operacao precisará ser alterado. Quanto mais lógica for adicionada, mais frágil e mais difícil de testar o código se tornará.

Aplicando o OCP com Polimorfismo

Podemos refatorar usando uma hierarquia de classes, permitindo adicionar novas operações sem modificar código existente:

from abc import ABC, abstractmethod

class Operacao(ABC):
    @abstractmethod
    def calcular(self, a, b):
        pass

class Soma(Operacao):
    def calcular(self, a, b):
        return a + b

class Subtracao(Operacao):
    def calcular(self, a, b):
        return a - b


def executar_operacao(operacao: Operacao, a, b):
    return operacao.calcular(a, b)


# Uso:
resultado = executar_operacao(Soma(), 2, 3)

Agora, para adicionar uma nova operação — por exemplo, uma multiplicação — basta criar uma nova subclasse:

class Multiplicacao(Operacao):
    def calcular(self, a, b):
        return a * b

Nenhuma modificação no código principal é necessária. Isso torna o design mais estável, previsível e fácil de evoluir.

Onde o OCP Brilha na Prática

  • Regras de negócio variáveis: Cálculo de comissões, descontos ou impostos que variam conforme o tipo de cliente ou o contrato.
  • Estratégias de notificação: Diferentes canais (email, SMS, push, WhatsApp) com uma interface comum.
  • Sistemas de plugins: Ferramentas extensíveis em que cada plugin adiciona comportamento por meio de subclasses.

Aliás, o padrão Strategy é uma aplicação direta do OCP, permitindo selecionar comportamentos em tempo de execução sem alterar código central.

Por Que Adotar o OCP

  • Facilita a evolução do sistema sem comprometer código validado.
  • Reduz o acoplamento e incentiva abstrações limpas.
  • Melhora a testabilidade, pois cada comportamento é isolado em sua própria classe.
  • Promove um design mais profissional, típico de projetos Python maduros.

Projetar com o Princípio Aberto-Fechado é dar um passo estratégico rumo a um código mais sustentável, que cresce com o produto — e não contra ele.



Riverfount
Vicente Eduardo Ribeiro Marçal

Em Python, é comum — especialmente pela flexibilidade da linguagem e pelo foco em produtividade — cairmos na armadilha de escrever grandes blocos de código em uma única função, método ou rota. Às vezes, é tentador resolver “tudo em um só lugar”: validar os dados, consultar o banco, tratar erros e ainda montar a resposta final.

Mas essa abordagem tem um preço. O código cresce, as responsabilidades se misturam e, de repente, você tem uma função que faz de tudo — e nada bem feito.

O que diz o Princípio da Responsabilidade Única (SRP)

Diretamente inspirado no primeiro princípio do SOLID, o SRP (“Single Responsibility Principle”) afirma que cada função, classe ou módulo deve ter apenas um motivo para mudar. Em outras palavras, cada unidade de código deve ter uma responsabilidade bem definida.

Isso melhora a legibilidade, reduz o acoplamento e torna o sistema muito mais fácil de evoluir.

Vamos ver um exemplo prático.

Exemplo: o anti-padrão

@app.route("/users", methods=["POST"])
def create_user():
    # 1. Validação
    data = request.json
    if "email" not in data:
        return {"error": "Email is required"}, 400

    # 2. Inserção no banco
    conn = sqlite3.connect("db.sqlite")
    cursor = conn.cursor()
    cursor.execute("INSERT INTO users (email) VALUES (?)", (data["email"],))
    conn.commit()
    conn.close()

    # 3. Notificação (simulada)
    send_welcome_email(data["email"])

    return {"message": "User created successfully"}, 201

Essa rota funciona, mas concentra três responsabilidades distintas: validação de dados, acesso ao banco e envio de e-mail. Isso viola o SRP.

Aplicando o princípio

Vamos refatorar o código, dividindo as responsabilidades:

def validate_user_data(data):
    if "email" not in data:
        raise ValueError("Email is required")

def save_user_to_db(email):
    conn = sqlite3.connect("db.sqlite")
    with conn:
        conn.execute("INSERT INTO users (email) VALUES (?)", (email,))
    return True

def send_notification(email):
    send_welcome_email(email)

@app.route("/users", methods=["POST"])
def create_user():
    try:
        data = request.json
        validate_user_data(data)
        save_user_to_db(data["email"])
        send_notification(data["email"])
        return {"message": "User created successfully"}, 201
    except ValueError as e:
        return {"error": str(e)}, 400

Agora a rota faz apenas o que deve: coordena o fluxo entre funções auxiliares. Cada função tem uma única responsabilidade clara e testável.

Por que isso é importante

  • Manutenibilidade: funções pequenas e claras são mais fáceis de entender e de modificar.
  • Testabilidade: testar cada parte isoladamente torna-se trivial, facilitando os testes unitários.
  • Reutilização: funções com responsabilidades únicas podem ser reaproveitadas em outros contextos.
  • Escalabilidade: um código modular cresce de forma mais previsível e segura.
  • Menor acoplamento: reduz a dependência entre componentes e torna o sistema mais flexível.
  • Mocks e stubs: com responsabilidades bem separadas, é mais fácil simular dependências em testes.
  • Depuração: localizar bugs é muito mais simples quando cada função faz apenas uma coisa.

Conclusão

Ao olhar para uma função, faça a si mesmo esta pergunta: “Quantas coisas ela faz?”. Se a resposta for mais de uma, é hora de quebrar o código em partes menores. O princípio da responsabilidade única não é apenas teórico — é uma forma prática de escrever código mais limpo, testável e confiável em Python.



Riverfount
Vicente Eduardo Ribeiro Marçal

Na prática de desenvolvimento, é comum ver blocos de código duplicados, copiados e colados em diferentes partes de um sistema. Parece inofensivo; afinal, “funciona”. Mas com o tempo, essa abordagem se torna um problema sério. É aqui que entra o princípio DRY — Don't Repeat Yourself — um dos fundamentos mais importantes da engenharia de software moderna.

O que é o princípio DRY

O princípio DRY afirma que cada informação, comportamento ou lógica de negócio deve ter uma única representação dentro de um sistema. Repetir código é repetir responsabilidade, e cada duplicação se transforma em um ponto a mais para corrigir quando algo muda.

Aplicar DRY significa centralizar responsabilidades, promovendo clareza, consistência e reutilização.

Por que o DRY é essencial

  • Manutenção simplificada: Se uma regra existe em apenas um ponto, basta atualizá-la uma vez para refletir sua mudança em todo o sistema.
  • Legibilidade e clareza: O código torna-se mais previsível, direto e fácil de entender.
  • Consistência entre módulos: As mesmas entradas sempre produzem as mesmas saídas.
  • Reutilização e escalabilidade: Abstrações bem definidas permitem evolução sem retrabalho.

Aplicando DRY na prática

1. Evitando repetição com funções

Sem DRY:

# Cálculo duplicado de imposto
def calcular_total_produto(preco, imposto):
    return preco + (preco * imposto) 


def calcular_total_servico(preco, imposto):
    return preco + (preco * imposto)

Com DRY:

def calcular_total(preco, imposto):
    return preco + (preco * imposto)

Agora, produtos e serviços usam a mesma função, reduzindo manutenção e riscos de inconsistência.

2. Aplicando DRY com classes e herança

Sem DRY:

class Funcionario:
     def __init__(self, nome, salario):
         self.nome = nome
         self.salario = salario

    def calcular_bonus(self):
        return self.salario * 0.10
        
        
class Gerente:
    def __init__(self, nome, salario):
        self.nome = nome
        self.salario = salario 
    
    def calcular_bonus(self):
        return self.salario * 0.20

Com DRY e Orientação a Objetos:

class Funcionario:
    def __init__(self, nome, salario):
        self.nome = nome
        self.salario = salario
        
    def calcular_bonus(self):
        return self.salario * 0.10


class Gerente(Funcionario):
    def calcular_bonus(self):
        return self.salario * 0.20

A herança elimina código repetido e mantém a lógica consistente entre tipos de funcionários.

3. Centralizando configurações

Sem DRY:

API_URL = "https://api.meusistema.com"
print("Enviando dados para https://api.meusistema.com")

Com DRY:

CONFIG = {
    "API_URL": "https://api.meusistema.com"
}

print(f"Enviando dados para {CONFIG['API_URL']}")

Quando for necessário mudar o endpoint, basta atualizar apenas um local.

4. Evitando duplicação de dados

Sem DRY:

usuarios = [
    {"id": 1, "nome": "Alice", "email": "alice@example.com"},
    {"id": 2, "nome": "Bob", "email": "bob@example.com"}
]

emails = ["alice@example.com", "bob@example.com"]

Com DRY:

usuarios = [
    {"id": 1, "nome": "Alice", "email": "alice@example.com"},
    {"id": 2, "nome": "Bob", "email": "bob@example.com"}
]

emails = [u["email"] for u in usuarios]

Assim, o código sempre obtém dados derivados diretamente da fonte original.

Quando não aplicar DRY cegamente

DRY é poderoso, mas abstrações em excesso podem transformar um código simples em algo complexo demais. Se duas partes do sistema compartilham apenas semelhanças superficiais, manter a duplicação temporariamente pode ser a melhor escolha. O equilíbrio é o segredo: Deduplique apenas quando houver real benefício em termos de clareza, manutenção e consistência.

Conclusão

O princípio DRY é mais que uma boa prática: ele reflete uma mentalidade de engenharia. Pensar em sistemas DRY é pensar em código sustentável, modular e de longo prazo.
Evitar repetição não é apenas sobre reduzir linhas, é sobre projetar bases sólidas para a evolução natural do software.



Riverfount
Vicente Eduardo Ribeiro Marçal

Os Type Hints transformaram a forma como escrevemos e mantemos código Python. Desde que foram introduzidos oficialmente no Python 3.5+, eles se tornaram essenciais em projetos que buscam clareza, segurança e manutenção mais fácil.

Mesmo sendo uma linguagem dinamicamente tipada, o Python se beneficia muito dessas anotações estáticas, especialmente em callables — funções, métodos e classes. Neste artigo, vamos entender por que usar Type Hints é uma prática que vale o investimento.

O que são Type Hints e por que importam

Type Hints (ou dicas de tipo) e Type Annotations (anotações de tipo) permitem indicar qual tipo de dado é esperado em parâmetros e retornos de funções — tudo sem alterar a execução do código. Isso fornece uma camada de documentação automática e dá às ferramentas de análise a capacidade de detectar erros antes da execução.

Com isso, o código fica mais previsível e mais fácil de entender, especialmente em equipes ou projetos de longo prazo. Vejamos, então, alguns pontos que nos auxiliem a compreender as vantagens de usar o Type Hints em nosso dia a dia.

1. Clareza na intenção

Callables anotadas explicitamente mostram a intenção do desenvolvedor. Em vez de adivinhar o tipo esperado, qualquer pessoa que leia a função entende rapidamente seu contrato de uso.

from typing import Sequence

def calculate_total(items: Sequence[float], discount: float = 0.0) -> float:
     """Calcula o total com possível desconto."""    
     subtotal = sum(items)
     return subtotal * (1 - discount)

Esse tipo de clareza se traduz em APIs mais legíveis e documentação quase desnecessária.

2. Melhor suporte a ferramentas

Ferramentas como mypy, Pylance (VS Code) e PyCharm são projetadas para aproveitar as anotações de tipo ao máximo. Elas oferecem:

  • Verificação estática de tipos antes da execução.
  • Autocompletar mais inteligente.
  • Detecção de inconsistências de tipo em tempo de desenvolvimento.

Esse feedback imediato reduz bugs e melhora a produtividade do time.

3. Código mais fácil de manter

Em projetos grandes, anotações de tipo funcionam como uma documentação que nunca fica desatualizada. Elas:

  • Eliminam a necessidade de abrir implementações para entender uma função.
  • Tornam refatorações mais seguras.
  • Diminuem erros ao passar parâmetros incorretos.

Manter consistência nas anotações é o segredo para que o benefício se estenda por toda a base de código.

4. Estabelecendo contratos explícitos

Ao usar Type Hints, você cria contratos claros — o que é essencial em APIs, bibliotecas e interfaces entre módulos. Esses contratos tornam o comportamento mais previsível e aumentam a confiabilidade do sistema. Em outras palavras: quem usa sua função sabe exatamente o que esperar dela.

Quando não anotar variáveis locais

Embora as anotações sejam úteis, nem tudo precisa ser anotado.
Para variáveis locais cujo tipo é óbvio, a inferência do Python faz um excelente trabalho:


# Desnecessário 
items: list[float] = [10.5, 20.0, 30.75] 
# Melhor assim 
items = [10.5, 20.0, 30.75]  # Tipo inferido como list[float]

Use anotações locais apenas em três situações específicas:

  • Quando a inicialização é complexa e o tipo não é evidente.
  • Em variáveis de classe.
  • Quando você precisa forçar um tipo específico.

Boas práticas para Type Hints em callables

  • Seja específico: use list[str], dict[int, str], etc.
  • Use o operador | para parâmetros com múltiplos tipos possíveis (ex.: int | str).
  • Use X | None em vez de Optional[X].
  • Documente exceções que os tipos não representem.
  • Mantenha consistência: uma vez que começar a usar type hints, aplique-os em todo o projeto.

Exemplo avançado


from typing import Iterable, Callable 

def process_data(
    data: Iterable[int],
    transformer: Callable[[int], int] | None = None,
    threshold: int = 0
) -> list[int]:
    """Processa dados aplicando transformação e filtro."""
    if transformer is None:
        transformer = lambda x: x
    return [transformer(x) for x in data if x > threshold]

Esse exemplo mostra como é possível expressar claramente a intenção e o comportamento, mesmo em funções mais complexas.

Conclusão

Usar Type Hints em callables é uma das formas mais eficazes de melhorar a qualidade e a legibilidade do código em Python. Eles unem o melhor dos dois mundos: dão à linguagem a segurança da tipagem estática sem perder sua natureza dinâmica e ágil. Adotar esse padrão não é apenas uma questão de estilo — é um passo estratégico para construir bases de código mais seguras, fáceis de entender e prontas para escalar.

P.S.: Uma informação importante

O Python não realiza validação de tipos em tempo de execução, mesmo quando as anotações de tipo estão presentes no código. As Type Hints têm caráter apenas informativo e não afetam a execução do programa em si. No entanto, essas anotações são amplamente utilizadas por IDEs e ferramentas de análise estática, como o mypy, que verificam a consistência dos tipos e ajudam a identificar possíveis erros antes da execução, tornando o desenvolvimento mais seguro e previsível.



Riverfount
Vicente Eduardo Ribeiro Marçal