Nesta edição os resultados da pesquisa sobre a comunidade Go, uma introdução a arquitetura orientada a eventos e posts sobre testes de integração e de goroutines. E mais uma chance de comprar o ingresso para a Gophercon Brasil 2024! Links Go Developer Survey 2024 H1 Results
Minha segunda observação é sobre o artigo de testes de integração, o setup e teardown em uma struct OK, faltou só o essencial, como organizar/colocar os testes em diferentes pacotes ou ter pelo menos um exemplo de teste.
Na minha experiência do mundo real o que facilitou essa abordagem foi usar o Gink (https://github.com/onsi/ginkgo) e os containeres Ordered e Serial dele...
Nunca programei em Java, então fiquei na duvida do que seria uma solução "Javesca"? e qual seria a estrutura "mais adequada" para se seguir nesse caso? Inclusive ficaria muito feliz de receber uma Pull Request sua com uma sugestão de melhorias nesse sentido.
Sobre os getters e setters, esse não era o foco do artigo, então eu poderia ter deixado todas as propriedades da struct como públicas e acessá-las diretamente. Mas acabei centralizando as mudanças da struct em métodos para ter controle das invariâncias e garantir que essa struct não tenha um estado inválido. Mas novamente, esse não era o foco do artigo, então essa parte é mais gosto pessoal mesmo e como eu costumo desenvolver no dia-a-dia.
De qualquer forma, qual o problema de utilizar getters? ja que a própria linguagem nos dar a possibilidade de privar propriedades da struct? Gostaria de entender de verdade uma explicação para esse seu ponto.
Sobre o link que você compartilhou, discordo em partes:
Essa citação me faz pensar se o autor realmente leu o livro: "ambos os livros são focados principalmente em linguagens orientadas a objetos de alto nível, especificamente Java. e C#".
Será ? Pois no livro de Clean Architecture do Uncle Bob que eu li, os exemplos práticos (os poucos que tem, pois o livro é mais teórico) são escritos a grande maioria na linguagem C, e alguns em C++.
É uma afirmação muito equivocada dizer que a Clean Arch deve ser utilizada em linguagens com orientação a objetos, sendo que no próprio livro tem exemplos de aplicação em linguagens funcionais e inclusive tem capítulos separando o uso dos conceitos em linguagens orientadas a objetos e linguagens funcionais (com capítulos inteirinhos somente para esse assunto). Obviamente que com a orientação a objeto você tem mais recursos e ferramentas, como interfaces, polimorfismo e etc. Mas é totalmente possível implementar em linguagens estruturadas ou funcionais sim ;)
Desculpe a franqueza mas essa semana senti que deveria opininar sobre a (falta de) qualidade de alguns artigos;
Primeiro sobre o artigo de event driven, a solução proposta é extremamente "Javesca", o autor até propõe fazer getter e setter em Go (???) além de organizar o código explicitamente numa arquitetura hexagonal o que não faz sentido (recomendação de leitura: https://robertoplazaromero.medium.com/why-you-shouldnt-use-hexagonal-architecture-with-go-a58bc9fcd2a3).
Minha segunda observação é sobre o artigo de testes de integração, o setup e teardown em uma struct OK, faltou só o essencial, como organizar/colocar os testes em diferentes pacotes ou ter pelo menos um exemplo de teste.
Na minha experiência do mundo real o que facilitou essa abordagem foi usar o Gink (https://github.com/onsi/ginkgo) e os containeres Ordered e Serial dele...
Nunca programei em Java, então fiquei na duvida do que seria uma solução "Javesca"? e qual seria a estrutura "mais adequada" para se seguir nesse caso? Inclusive ficaria muito feliz de receber uma Pull Request sua com uma sugestão de melhorias nesse sentido.
Sobre os getters e setters, esse não era o foco do artigo, então eu poderia ter deixado todas as propriedades da struct como públicas e acessá-las diretamente. Mas acabei centralizando as mudanças da struct em métodos para ter controle das invariâncias e garantir que essa struct não tenha um estado inválido. Mas novamente, esse não era o foco do artigo, então essa parte é mais gosto pessoal mesmo e como eu costumo desenvolver no dia-a-dia.
De qualquer forma, qual o problema de utilizar getters? ja que a própria linguagem nos dar a possibilidade de privar propriedades da struct? Gostaria de entender de verdade uma explicação para esse seu ponto.
Sobre o link que você compartilhou, discordo em partes:
Essa citação me faz pensar se o autor realmente leu o livro: "ambos os livros são focados principalmente em linguagens orientadas a objetos de alto nível, especificamente Java. e C#".
Será ? Pois no livro de Clean Architecture do Uncle Bob que eu li, os exemplos práticos (os poucos que tem, pois o livro é mais teórico) são escritos a grande maioria na linguagem C, e alguns em C++.
É uma afirmação muito equivocada dizer que a Clean Arch deve ser utilizada em linguagens com orientação a objetos, sendo que no próprio livro tem exemplos de aplicação em linguagens funcionais e inclusive tem capítulos separando o uso dos conceitos em linguagens orientadas a objetos e linguagens funcionais (com capítulos inteirinhos somente para esse assunto). Obviamente que com a orientação a objeto você tem mais recursos e ferramentas, como interfaces, polimorfismo e etc. Mas é totalmente possível implementar em linguagens estruturadas ou funcionais sim ;)