Recentemente participei de um treinamento com arquitetos da Pivotal (Spring & Springboot).
Eles falaram sobre N coisas, incluindo kotlin, jpa x jdbc e arquitetura.
Quando o assunto foi lombok e feign, eles foram categóricos em dizer que ambos podem ser evitados. Mais que isso, devem ser evitados nos projetos em que não se façam necessários.
Além, claro, do eureka e outras ferramentas que comumente achamos ser a bala de prata.
2 curtidas
Com certeza, no JDK 11 a gente já vê o uso do var, ao invés de String e int, como o Darlan falou, em questão de tempo isso será um padrão
@Getter @Setter
private String nome;
Por enquanto a gente só pode esperar os caras mudarem um pouco. Mas uma coisa que eu vi em Python e que achei bem legal, é que não é necessário declarar o nome da classe, fora tantas outras facilidades do python.
O Java tem muito potencial pra melhorar, acredito que com essas mudanças na Oracle, pode ser que haja algum avanço
1 curtida
O Eclipse não sei, mas no IntelliJ vi que não coloca import static automaticamente.
Não conheço tanto o C#, mas pra quem concorda que ela é mais limpa que Java, de que forma ela é mais limpa?
Dependendo do código, vc só consegue dizer se é Java ou C# porque o método em C# costuma começar com letra maiúscula e as chaves costuma vir na linha de baixo.
C# tem o val, mas agora Java tem o var. Embora C# tenha bem mais recursos que Java, no quesito “código limpo” o único recurso que pesa mais são as properties, mas ainda sim é verboso.
O que vcs acham?
Sobre o Lombok, não o conhecia, mas gostei muito, tomara mesmo que se torne padrão ou que achei um jeito ainda melhor de implementar no core da linguagem.
Quer dizer que não impacta em nada na performance do runtime, mas, dependendo do tamanho do projeto, pode impactar no tempo de build, certo?
É mesmo, pode causar uma certa confusão a principio, mas se importar coisas estaticamente se torna-se um padrão na comunidade ou, pelo menos, dentro da empresa, pode se tornar mais natural eu acho.
Além disso, bastaria botar o mouse em cima do método pra IDE dizer da onde ele vem.
Bom, mas independente disso, pelo que todos disseram, seria mais seguro não usar este recurso na maioria das vezes. É melhor deixar pra usar apenas em bibliotecas ou frameworks que já padronizaram o uso como o Mockito ou o JUnit.
1 curtida
Pense em um iniciante procurando um tutorial e dando de cara com a invocação a um método estático. Esse é o cenário que mais vejo. Até explicar que aquele método invocado é um método estático, declarado no import e blablablá, já criou-se uma confusão gigante.
Além disso, não é por que existe e funciona que deve-se usar. É o caso do goto. É uma palavra reservada do java, mas, você já usou? Recomenda?
DefaultTableModel para Swing, idem.
Concordo com o que o @staroski comentou: usar padrões de desenvolvimento como SOLID e clean code garante uma legibilidade maior ao código (o clean code parte do princípio que você escreve código legível, sem necessidade de comentários para explicar o que está fazendo. O pessoal da Pivotal foi bem enfático neste ponto: código bom é código legível).
P.S.:
Também não, ao menos até a versão 2019.2
2 curtidas
Concordo sobre C# ser mais verboso que Kotlin. Mas só quis dizer que Java é bem mais verboso que ambas.
Não entendi sobre chamar React de linguagem, mas dificilmente adotaria ferramentas desse tipo, pela característica que você citou. Achei uma zona pelo que vi até entao, mas por outro lado acredito que seja algo mais tranquilo pra cabeça dos mais jovens…
1 curtida
Não é uma linguagem, mas uma característica bem forte do JavaScript, assim como o Flutter.
Não que seja uma zona, mas pra que não está acostumado, como o Adriano comentou, pode ser algo extremamente estranho de se olhar, mas com o tempo acaba acostumando.
Querendo ou não, o JS tem se tornado muito forte de uns anos pra cá, em todos os aspectos, Web, Desktop, Mobile… É uma linguagem pra dar mais atenção
Um prato cheio esse tópico. Valeu pela contribuição de todos.
@staroski, a parte sobre os getters me chamaram atenção. Você acha que é uma boa solução mesmo isso? Atualmente crio todos meus atributos privados, colocando getter sempre.
1 curtida
Eu realmente queria entender mais isso aqui. Utilizamos Lombok em um Projeto legado com mais de 40 Services e muitas, mas muitas classes abaixo mesmo que utilizam Lombok e nenhuma delas tem um problema de achar um getter ou setter de outra. Você teve esse problema? Pode explicar o cenário que isso ocorreu?
A menos que você esteja falando de usar Java sem IDE. Alguém já tentou a sorte?
Quanto ao fato de executar em tempo de compilação, esse é o papel das anotações, anotações que são um recurso da linguagem, não vejo gambiarra.
Você pode dizer que anotações são gambiarras e que teriam um jeito “melhor” de fazer incluindo em tempo de execução ou escrita de código, mas chamar um recurso de uma linguagem de gambiarra porque tem uma forma que você acha melhor tem tópico pra discussão, porque claro que você pode estar certo, mas a decisão de implementar de uma forma em uma linguagem tão grande como é a de Java e na época que a decisão foi tomada ao incluir as annotations, ouso dizer que tem um motivo muito forte, sendo que foi tomada por vários players cruciais na época.
Gambiarra é quando se precisa pegar o valor do registrador puro em C/C++ e object Pascal.
E não quando se faz uso de Anotações em Java.
1 curtida
Sei disso, mas eu só uso recursos do js que forem necessários pro projeto, nada que vá deixar a funcionalidade sem saber onde começa e termina.
Sim, funcionava na IDE, mas o problema foi que, sem ninguém saber, alguém havia configurado o projeto para usar Lombok e acabou refatorando algumas classes e criando classes novas com as annotations.
Aí, de repente, o ambiente de integração contínua começou a “explodir” sem ninguém entender, pois havia erros de compilação.
Resumindo, as builds do Jenkins, que eram mantidas por outra equipe, não estavam configuradas para incluir o annotation proccessor do Lombok durante a compilação, então isso gerou todo um estresse na equipe de desenvolvimento e na gerência do projeto.
Isso sim, vejo como gambiarra a característica de ele na verdade ser uma espécie de “estensão do compilador”, pois ele permite que um código esteja semanticamente errado do ponto de vista do javac.
Mas também também considero gambiarra por exemplo o bytecode instrumentation que o Hibernate e o AspectJ fazem no código.
O Lombok tem recursos interessantes? Tem!
Mas acredito que vai muito da maneira que cada um tem de desenvolver.
Acho super importante que em qualquer projeto, a adoção desse tipo de framework seja muito bem documentada, principalmente em projetos maiores onde possa haver diversas equipes trabalhando em diferentes frentes do desenvolvimento do produto.
Os getters e setters costumam ser simplesmente um accessor e mutator de um atributo private, sem nenhuma lógica ou validação por trás deles.
O próprio Robert Cecil Martin (autor do clean code), diz que os getters e setters expõe um atributo private como se ele fosse public.
Neste caso basta tornar o atributo public de uma vez, assim você escreve menos.
Acho que getters e setters só fazem sentido quando fazem parte de uma interface, pois uma interface define o comportamento de um objeto.
Então se você tem um set e um get em uma interface, você já está preparado que haverá polimorfismo e que pode haver alguma validação.
Falando de uma forma mais fácil de entender, eu vejo que os getters e setters podem fazer sentido em classes que vão representar um objeto polimórfico.
Mas são completamente desnecessários em classes que vão simplesmente representar uma estrutura de dados, um conjunto de informações ou um data transfer object.
Entendi. Ainda não considero gambiarra, mas consigo entender porque é considerado, levando em conta o discurso mais purista.
1 curtida
Sempre achei isso bizarro. Os tais objetos anêmicos. Não possuem comportamento e nem sequer se auto-validam, logo como apenas repositórios de dados onde se pode incluir o que quiser, é perda de tempo mesmo incluir métodos acessores.
1 curtida
Sim, mas estou falando do que o programador lê, chamando um método .getAlgumaCoisa que não existe no seu código. Se for pra ter algo nativo, que façam direito implementando property, não essa coisa ai.
1 curtida
Não é o único, o que posso lembrar no momento:
Métodos de extensao direto na instancia
Interpolacao de string
Tratamento de assincronicidade na própria linguagem
LINQ (streams do java que seria o mais próximo é um terror perto do LINQ do C#, java ainda peca muito no funcional)
2 curtidas
Sim, por isso que eu, Ricardo Staroski, considero gambiarra. Risos.
Se fosse nativo da linguagem, eu não iria considerar.
Até o Object Pascal já tinha properties, o Java também poderia ter. Declarava o atributo como property e só escreveria explicitamente o getter e/ou setter, caso quisesse incluir alguma lógica ou validação…
2 curtidas
Isso ainda não vi como é no C#, mas legal, acredito que seja muito bom.
O LINQ é interessante, mas as streams do Java são bem legais também.
Sobre o suporte do Eclipse ao import static, vi que se vc tem o seguinte código:
import java.util.List;
public class Main {
public static void main(String... args) {
System.out.println(List.of("a", "b", "c"));
}
}
E clicar com o direito na palavra of, ir em Source → Add Import ou pressionar Shift + Crtl + M ele adiciona a seguinte linha ao código:
import static java.util.List.of;
Já ajuda um pouco.