Bruno Rocha ★ rochacbruno on Nostr: Padrões de Projeto 20 anos trabalhando profissionalmente com #python e já atuei em ...
Padrões de Projeto
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:
Decorator lru_cache
Strategy len(...)
Mediator 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.concluindo
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.
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:
Decorator lru_cache
Strategy len(...)
Mediator 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.concluindo
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.