Boa noite pessoal,
Estava dando uma olhada nessa lib e ela me pareceu interessante, pois usa anotações pra gerar todo o código padrão de classes (get, set, equals, toString, etc) mas não vi tanta adesão à ela, aí veio a dúvida, “Será que não vale a pena?”. Vocês indicariam? Sei que ela não revoluciona nada, mas parece ser uma adição bem-vinda.
Eu usei em alguns projetos e gostei muito. Ajuda bastante a reduzir a verbosidade excessiva do java.
Porém, tudo tem um custo. Ela também traz alguns problemas:
- Como precisa do plugin para a IDE, ela complica a preparaçao do ambiente para um novo desenvolvedor. Nao é muito difícil, mas é uma etapa a mais no processo.
- É preciso etapas extras no processo de build, se tiver usando ferramentas de análise estática de código (tipo Sonar)
- E principalmente, com as mudanças em pacotes internos no java 9 e 10, é preciso verificar se ela vai continuar funcionando do mesmo jeito.
1 curtida
Mascara algumas deficiencias da linguagem Java para produtividade, mas nunca vi sendo usado profissionalmente.
1 curtida
Particularmente detesto pois permite a criação de código Java sintaticamente errado.
Isso acaba sendo péssimo para ensinar iniciantes.
Não vejo utilidade em usar suas anotações somente para gerar getters, setters, equals, hascode e toString até porque toda IDE moderna possui suporte à isso.
Para mim o lombok é uma solução pra um problema que não existe.
2 curtidas
Tambem nunca usaria isso, mas a proposta dessa ferramenta é tambem deixar o codigo mais limpo, pois é desesperador ver um codigo Java.
@castilho.glauco, se é pra usar Java use Java como ele é, senao use uma linguagem menos complicada. Para o mercado, usar essa ferramenta só vai te atrapalhar em relação a como a maioria usa Java. Se um dia a própria linguagem Java evoluir nisso, ai sim você usa a nova forma que criarem.
1 curtida
Vejo que códigos são desesperadores porque muitos professores orientam de maneira ruim, sem ensinar boas práticas e, muitas vezes, sem ter experiência no meio profissional, somente acadêmico.
1 curtida
Apenas para esclarecer alguns pontos:
Eu nao apenas já usei profissionalmente como já vi sendo usado e discutido em vários lugares.
A quantidade de gente que usa Java é muito grande pra saber o que a maioria tá fazendo. Escolher tecnologias usadas em produçao que sobreviveram ao hype já costuma dar segurança, e Lombok já passou dessa fase.
Acho que é questao de opiniao. Para mim, é similar a dizer que o java nao precisava de lambdas pois possuia classes anônimas. O Guava implementou várias alternativas funcionais mas pouca gente adotava, pré java 8, devido a verbosidade de usar. Hoje em dia é muito comum ver lambdas sendo usadas.
Apesar das IDEs criarem esses métodos, é trabalhoso ter que ficar ajustando esses métodos (especialmente equals e hashcode) quando as entidades mudam com o tempo. Já perdi muito tempo em código review com esse tipo de código que é totalmente mecânico.
E por fim, há várias boas práticas embutidas nas anotaçoes do lombok, como criando classes imutáveis e builders, com bem menos burocracia do que fazendo tudo na mao.
Se teu foco é ensinar inicialmente, realmente eu ficaria longe desse tipo de ferramenta (mas talvez até mesmo de java). Para o dia a dia eu acho que economiza bastante tempo.
2 curtidas
A poluição de métodos get/set da linguagem Java deve ter sido um dos maiores motivadores para criarem esse lombok. Seja em Java ou C# é comum para quem trabalha com banco de dados relacional ter “classes de dados” para representar diretamente o resultado de um SQL, sem complicações de modelo OO. Kotlin por exemplo é a que melhor expressa isso. Se existe outro meio em Java realmente não ensinam ou não é encorajado.
1 curtida
Concordo, é solução pra um problema que existe no Java em relação a outras, assim como lambda foi positivo mesmo com todo o atraso. Mas a maioria das grandes empresas não arriscam.
1 curtida
Sim, concordo.
Depende como se opta em implementá-los, eu também não gosto do código gerado pelas IDE’s, existem API’s de terceiros que facilitam, como os builder da Apache. Particularmente utilizo sempre um framework próprio, utilizando o padrão Strategy, se demonstrou ser mais performático e de fácil manutenção.
É possível que sim. Vejo que o maior problema é insistirem em ensinar getters e setters simplesmente para acessar atributos privados os quais não há nenhuma regra ou validação a ser aplicada, ou seja, é uma situação onde é melhor utilizar atributos públicos.
1 curtida
Concordo. Se eu programasse em Java teria vontade de fazer exatamente isso, mas sei que isso não é encorajado, seria crucificado. Nem nas tribos do C# isso é bem visto, e olha que pegam mais leve que a comunidade Java.
Bom, julgando pelas opiniões e experiências de vocês, acho que é o tipo de ferramenta que até pode ter sido mais útil quando foi criada, mas que nunca teve real adesão da comunidade e hoje acabou meio que sendo incorporada pelas IDEs.
Nao exatamente. Ainda é tao útil para Java quanto foi no começo. Até adotarem data/case classes no java, acho que ainda vale a pena.
Mas faz o seguinte: nao precisa se guiar pela minha opiniao ou pela opiniao dos outros colegas que participaram. Faz um teste no projeto que tá. Se teu time nao é muito grande, o maior trabalho é instalar o plugin para a IDe que você usa. Vê se gosta. Nao tem aprendizado melhor do que você ter a experiência.
1 curtida
Embora pela minha experiência nunca tenha visto uma equipe de Java usando isso e nem eu seria a favor de adotar, concordo com @AbelBueno, até hoje isso ainda melhora a poluição do Java. A IDE gera por exemplo get/set, mas o lixo vai ficar ali para os atributos mapeados que não são necessários no momento.
1 curtida
Pois é cara, acho que vou acabar fazendo isso mesmo, nem que seja só em casa pra sentir a diferença.
Acho o lombok legal, mas precisamos pensar em modelagem tática para não gerarmos getters e setters para tudo. Pensemos SOLID certo?
Concordo.
No ambiente em que estou inserido atualmente utilizamos Lombok, mas nem sempre é a melhor alternativa, depende muito do contexto geral do que se está sendo feito para ver sua aplicabilidade.
1 curtida
Eu tô usando Lombok e tô achando praticamente essencial para redução de código, especialmente quando se trata de POJOs/JavaBeans
1 curtida
Exatamente, diminui significativamente a verbosidade, deixa as classes muito mais limpas!
1 curtida