20 anos trabalhando profissionalmente com #python e já atuei em projetos de diversos nichos e tamanhos.
Uma linguagem 100% orientada a objetos e nunca precisei me preocupar com Padrões de Projeto de Software, nunca precisei parar para pensar se iria implementar Strategy ou Factory por exemplo, a energia do meu trabalho sempre foi 100% despendida em analisar -> codificar -> testar -> repetir, tudo interativamente (e iterativamente).
Um projeto Python geralmente começa em um único script, sem padrão, que depois vai se desmembrando em módulos, depois vira pacote, incremental e gradual.
Isso não quer dizer que nunca usei os padrões, o que to querendo dizer é que nunca precisei pensar neles, mesmo quando criei bibliotecas e frameworks, só precisei pensar no problema, no objetivo, no resultado e nas garantias.
Eu criei muitos CMS com multi site, multiplos tipos de conteúdo, RBAC etc.
Neste tipo de sistema a taxonomia do conteúdo é o ponto central, geralmente o padrão Strategy é o adotado, qualquer entidade que implementa "ContentType" pode ser criada, editada, exibida. Mas mesmo ao criar esses sistemas, nunca precisei pensar no padrão Strategy, é uma coisa tão trivial com Python que só depois de pronto que vc para e pensa "ahh isso parece Strategy"
A parte de notificações ou sinais também é algo que acontece naturalmente trocando mensagens entre os objetos e quando vc vai ver.. "ahh isso parece um Observer"
Em Python os padrões já estão todos intrínsecos na linguagem, a natureza dinâmica e duck typing fez com que não tenha sido necessário pensar nisso.
Veja esse trecho de código:
@lru_cache
def imprime(texto: str):
if len(texto) > 5:
texto = texto.upper()
print(texto)
imprime("Bruno") # Bruno
imprime("Batata") # BATATA
Um código orientado a objetos sem a necessidade de escrever nenhuma classe!
Só neste exemplo bobo temos os seguintes padrões de projeto:
lru_cache
len(...)
Abstração do print
Mas ninguém (provavelmente nem os core devs) precisam pensar nisso.
Inclusive, tem aqui um fato paradoxal, já vi muitos projetos em Python, que falharam ou se tornaram insustentáveis, ou são bons porém difíceis de usar e contribuir justamente pq os desenvolvedores quiseram focar muita energia em definir padrões de projetos tradicionais e pouca em resolver o problema.
Um exemplo clássico é o SQLAlchemy, que éexcelente e eu adoro usar!
Mas é preciso reconhecer que ele é difícil de entender, ele implementa muitos padrões quase à risca, como por exemplo o Repository
que é ótimo para ser uma ferramenta que abrange diferentes casos de uso e até outras implementações baseadas nela, porém é difícil de entender, é difícil de contribuir, iniciantes e experts sempre se perguntando "pq tal coisa é assim no sqla"? e a resposta é quase sempre "para seguir um padrão".
Em projetos onde tenho que trabalhar com outras pessoas acabo preferindo ir para abstrações em cima dele como o SQLModel, ou se a modelagem do BD for simples eu prefiro usar SQL puro, ou até mesmo ORMs mais user friendly como o Tortoise (que inclusive é otimo e async) ou Peewee.
Eu estava pensando nisso hoje, pq precisei colocar as mãos em um projeto Java, a reescrita de um código Python para Java (por motivos específicos de licença e plataforma), e como não mexia com Java desde 2006 (faculdade) eu tive que dar uma estudada, e a primeira coisa que me deparei foi com a necessidade de pensar em padrões, bom, resolvi o problema, mas não foi fluido, talvez seja pq eu nao sou fluente em javês.
Ontem fiz a brincadeira de implementar o mesmo código em Rust, e a experiência foi exatamente a mesma do Python! não precisei pensar nos padrões (claro que tive que pensar em outras coisas não relacionadas, como gestão de memória) mas o código em si, apenas fluiu sem me preocupar com qual padrão estaria adotando, é claro que neste caso não temos uma linguagem orientada a objetos, porém, o uso de traits é tão intrínseco da línguagem que você só faz e quando vai olhar percebe "ahh parece Strategy" mas não teve que pensar nisso.
Eu to reservando 1h/dia para aprender mais de Go, amanhã vou tentar replicar o código e ver qual a sensação, não sou fluente em Go, me sinto muito desconfortável com a sintaxe, mas quero aprender para contribuir com alguns projetos, eu tenho a impressão de que essas preocupações também não serão necessárias em Go.
Na minha opinião, a discussão de padrões de projeto é "masturbação intelectual" de quem gosta muito de OOP, boa parte dos softwares que resolvem problemas é desenvolvido sem que isso seja uma preocupação.
Aquisição de recursos, Complexidade Ciclomática, Estrutura de Dados, legibilidade e principalmente dominio das regras do negócio são muito mais importantes.
@bruno muito interessante a sua perspectiva!
Como você deve saber os padrões de projeto vieram das idéias do Christopher Alexander para problemas recorrentes em arquitetura e urbanismo, talvez nessas linguagens de alto nivel que já "resolvem" mais naturalmente os tipos de problema descritos originalmente pela gangue dos quatro, talvez esteja na hora de tentar catalogar e fazer sugestões [de padrões] para problemas num grau acima de abstração sabe... tipo, os padrões agora seriam sobre CRUD, autenticação, sincronização (chutando aqui pq não sou desenvolvedor profissional). Você conhece essa serie aqui? https://aosabook.org/en/index.html
@villares essa série é muito interessante, tenho salvo aqui um dos capitulos dela sobre o SQLAlchemy, não compreis os livros, só li o que tem no site.