Riverfount

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

Este artigo mostra como aplicar Abstract Base Classes (ABC) em um projeto real robusto, focado no desenvolvimento de microserviços. O objetivo é garantir clareza, contratos explícitos e extensibilidade, aliando os conceitos a práticas modernas.

Contexto do Projeto

Imagine um sistema de microserviços para gerenciamento de pedidos, em que diferentes serviços precisam manipular objetos que representam entidades diversas, como Pedido e Cliente. Queremos garantir que todas as entidades sigam um contrato explícito para operações comuns (ex.: obter ID, validação). Além disso, há um repositório genérico para armazenar dados dessas entidades com verificação de tipo.

Definição da ABC para Entidades

Criamos uma Abstract Base Class chamada Entity com métodos abstratos para garantir que toda entidade implemente os comportamentos necessários:

from abc import ABC, abstractmethod

class Entity(ABC):
    @abstractmethod
    def id(self) -> int:
        """Retorna o identificador único da entidade."""
        pass

    @abstractmethod
    def validate(self) -> bool:
        """Valida as regras de negócio da entidade."""
        pass

Implementação Concreta das Entidades

Exemplo de uma entidade Order (Pedido) que implementa a ABC e regras específicas:

class Order(Entity):
    def __init__(self, order_id: int, total: float) -> None:
        self._order_id = order_id
        self.total = total

    def id(self) -> int:
        return self._order_id

    def validate(self) -> bool:
        # Validação simples: total não pode ser negativo
        return self.total >= 0

Outro exemplo com Customer (Cliente):

class Customer(Entity):
    def __init__(self, customer_id: int, email: str) -> None:
        self._customer_id = customer_id
        self.email = email

    def id(self) -> int:
        return self._customer_id

    def validate(self) -> bool:
        # Validação simples: e-mail deve conter '@'
        return '@' in self.email

Repositório Genérico para Armazenar Entidades Validando Antes

A seguir, um repositório que aceita apenas entidades válidas, usando o tipo genérico limitado para Entity:

from typing import TypeVar, Generic, List

T = TypeVar('T', bound=Entity)

class Repository(Generic[T]):
    def __init__(self) -> None:
        self._items: List[T] = []

    def add(self, item: T) -> None:
        if not item.validate():
            raise ValueError(f"Invalid entity: {item}")
        self._items.append(item)

    def get_by_id(self, entity_id: int) -> T | None:
        for item in self._items:
            if item.id() == entity_id:
                return item
        return None

    def get_all(self) -> List[T]:
        return self._items

Uso Prático no Microserviço

def main():
    order_repo = Repository[Order]()
    customer_repo = Repository[Customer]()

    order = Order(1, 150.0)
    invalid_order = Order(2, -10.0)  # Total inválido

    customer = Customer(1, "user@example.com")
    invalid_customer = Customer(2, "invalid_email")  # E-mail inválido

    order_repo.add(order)
    try:
        order_repo.add(invalid_order)
    except ValueError as e:
        print(e)

    customer_repo.add(customer)
    try:
        customer_repo.add(invalid_customer)
    except ValueError as e:
        print(e)

    print("Pedidos:")
    for o in order_repo.get_all():
        print(f"ID: {o.id()}, Total: {o.total}")

    print("Clientes:")
    for c in customer_repo.get_all():
        print(f"ID: {c.id()}, Email: {c.email}")

if __name__ == "__main__":
    main()

Benefícios desse padrão no projeto real

  • Contratos explícitos: A ABC obriga à implementação dos métodos id e validate.

  • Segurança em tempo de execução: Objetos inválidos não serão adicionados ao repositório.

  • Reuso e manutenibilidade: O repositório é genérico e reutilizável com qualquer entidade.

  • Facilidade para testes: É simples isolar e testar entidades e repositórios separadamente.

  • Escalabilidade: Novas entidades podem ser criadas seguindo o contrato, sem mudanças na infraestrutura do repositório.

Conclusão

Esta abordagem demonstra o poder das ABCs combinadas com generics e tipagem avançada, garantindo sistemas Python mais estruturados, robustos e suscetíveis a erros minimizados, essenciais para microserviços confiáveis e manteníveis. Se desejar, posso aprofundar a integração com outros padrões ou frameworks.



Riverfount
Vicente Eduardo Ribeiro Marçal

Este artigo aborda como usar funcionalidades avançadas de tipagem em Python, como Protocols, Generics e técnicas avançadas de typing, para criar aplicações escaláveis, flexíveis e de fácil manutenção.

Protocols: Contratos Flexíveis e Estruturais

Protocols permitem definir contratos de métodos e propriedades sem herança explícita, facilitando a interoperabilidade entre microserviços. Qualquer classe que implemente os métodos definidos no protocolo pode ser usada onde esse protocolo é esperado.

Exemplo prático:

from typing import Protocol

class Serializer(Protocol):
    def serialize(self) -> bytes:
        pass

class JsonSerializer:
    def serialize(self) -> bytes:
        return b'{"user": "alice"}'

class XmlSerializer:
    def serialize(self) -> bytes:
        return b'<user>alice</user>'

def send_data(serializer: Serializer) -> None:
    data = serializer.serialize()
    print(f"Enviando dados: {data}")

send_data(JsonSerializer())
send_data(XmlSerializer())

Neste exemplo, send_data aceita qualquer objeto que implemente o método serialize, garantindo baixo acoplamento e flexibilidade.

Generics: Componentes Reutilizáveis e Tipados

Generics permitem criar classes e funções genéricas que mantêm a segurança de tipos, facilitando a modularidade.

Exemplo de repositório genérico:

from typing import TypeVar, Generic, List

T = TypeVar('T')

class Repository(Generic[T]):
    def __init__(self) -> None:
        self._items: List[T] = []

    def add(self, item: T) -> None:
        self._items.append(item)

    def get_all(self) -> List[T]:
        return self._items

class User:
    def __init__(self, username: str) -> None:
        self.username = username

user_repo = Repository[User]()
user_repo.add(User("alice"))
for user in user_repo.get_all():
    print(user.username)

Este padrão permite criar repositórios ou caches que funcionam com qualquer tipo de objeto, aumentando a reutilização e segurança de tipos.

Tipagem Avançada: Operador | e Literal

Prefira o operador | para tipos alternativos ao invés de Union e use Literal para valores fixos, reforçando contratos claros.

Exemplo:

from typing import Literal

def login(role: Literal['admin', 'user', 'guest']) -> str:
    if role == 'admin':
        return "Acesso total"
    elif role == 'user':
        return "Acesso limitado"
    return "Acesso restrito"

print(login('admin'))  # Acesso total

Isso aumenta a legibilidade e reduz riscos de erro nas chamadas de função.

Conclusão

Combinando Protocols, Generics e tipagem avançada, é possível construir aplicações com contratos claros, flexíveis e robustos, facilitando o trabalho em times desacoplados e a manutenção do código.

Essas práticas elevam a qualidade do código e tornam os sistemas mais escaláveis e confiáveis, sendo indispensáveis para desenvolvedores focados em arquiteturas modernas, principalmente as de microserviços.



Riverfount
Vicente Eduardo Ribeiro Marçal

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