Import static, economia ou caos?

Concordo com o blogueiro: é uma economia que só faz sentido em alguns poucos casos (gostei do exemplo das static inner classes), mesmo porque eu acho estranho como fica o código em alguns casos:

import static java.lang.Math.*;
// várias linhas depois...
int i = abs(-1); // de onde veio este abs()?

É, qualquer IDE decente compensa essa “economia”… Mas pra manutenção do código imagino que isso deve atrapalhar bastante mesmo… Estranho terem se preocupado em incluir isso…

Caos. Chaos. Kaaos.

Gostaria de contribuir com uma opinião diferente, mas neste caso não dá.

Talvez se surgem algo tipo best practices de fazer o import static de classe de logger, ou alguma outra coisa que se repete muito, mas… no exemplo do Daniel, se o código está dentro de uma classe interna, primeiro eu tenho que ver se essa classe interna tem aquele método? Não? Então uma das superclasses da classe tem o método? Não? A classe que contém a classe interna tem o método? Não? Uma das superclasses daquela classe tem o método? Não? etc. Com um IDE decente fica fácil identificar onde que o método foi definido, mas com tal IDE fica fácil escrever código sem esse recurso de import static.

[]s,
Sami

Sabe onde fica mais divertido? Descobrir qual import estatico veio de onde quando vc esta usando overloads!

Ahahah, nem pensei nisso. Parece que você está falando de experiência

Olá

Concordo com vocês. mas é preciso lembrar um dos principais motivos porque isto foi incluído. Interfaces foram feitas para definir tipos e a galera, seguindo o mal exemplo da Sun no próprio Java, estava abusando das interfaces como repositório de constantes. Isto engessa um pouco o código.

Acho que o uso disto deve ser regulado com algumas regrinhas de boas práticas. Na maior parte das vezes pode dificultar a leitura do código mas em alguns casos pode ser vantajoso. Acho vantajoso somente nos casos em que o programador implementava interfaces para evitar codificar o caminho completo da classe e as constantes já apareciam sem pai nem mãe com os incovenientes que vocês citaram.

[]s
Luca

Olha…concordo com o pessoal…
o import static deixa o código meio caótico…acho que na hora da gente fazer manutenção no código…fica louco se o cara tiver vários import static…tem que ficar vendo daonde os metodos vieram…nossa dor de cabeça! :shock:

Ja era bom nao ter static, pra comeco de conversa…

Cara, eu definitivamente não entendi o que você quis dizer com isso…

Forçando a barra, dá pra fazer com que qualquer coisa de uma linguagem se torne algo difícil de ler (até usando cadeia de if, por exemplo).

Se faz tanta diferença assim saber de onde veio, deixa sem import static. Mas as vezes acontece de você ter uma classe MinhaClasseQueSoServePraGuardarConstantes e tem que usar 3 atributos estáticos dessa classe na mesma linha. Nesses casos, o static import facilita muito e deixa o código bem mais fácil de ler.

Cara, eu definitivamente não entendi o que você quis dizer com isso…
eu também não!

Cara, eu definitivamente não entendi o que você quis dizer com isso…
eu também não!

Er, não entenderam que import static não fazia falta, ou oque?

Cara, eu definitivamente não entendi o que você quis dizer com isso…
eu também não!

Er, não entenderam que import static não fazia falta, ou oque?

Não entendi por que ele disse que não devia ter “static”… Deu a entender que não devia existir elementos estáticos no geral…

caos! sem duvida!

deixa eu apoior o cv e ir alem: static, protected e extends deveriam ir embora (menos extends de interfaces, claro)…

o gilad bracha vive comentando, que seria tao bom poder criar uma nova versao do java sem manter a compatibilidade…

Paulo Silveira:

caos! sem duvida!

deixa eu apoior o cv e ir alem: static, protected e extends deveriam ir embora (menos extends de interfaces, claro)…

o gilad bracha vive comentando, que seria tao bom poder criar uma nova versao do java sem manter a compatibilidade…

meu deus…que odio de herança…ahuahuahuah poxa…só que interfaces não dá para fazer tudooooo, todo recurso tem o momento de ser usado

Paulo, como vc vai matar extends de interfaces? Eu acho tao bonitinho

utilizo “import static” somente quando realizo testes unitários com o EasyMock

UmaClasseQualquer objeto = EasyMock.createMock(UmaClasseQualquer.class)
EasyMock.expect(objeto.getPeso()).andReturn(12);
.....
EasyMock.replay(mock);
....
EasyMock.verify(mock);

UmaClasseQualquer objeto = createMock(UmaClasseQualquer.class)
expect(objeto.getPeso()).andReturn(12);
.....
replay(mock);
....
verify(mock);

Creio que facilita!

Para métodos estáticos até que concordo, mas para o caso de constantes? Já que não podemos trocar o “static final” por “const / define” o que fazer? Deixar o código cheio de números mágicos?

Eu acho que o uso de static imports fica legal com enums, por exemplo.

Seria legal também pra desafios: Descubra de onde vêem esse método. Aí existem uma cambada de programadores, fuçando pacotes, classes e APIs. No final, o cara decorou o projeto inteiro como se fosse o criador, e um ganhador iria receber uma medalha + bônus de garoto paciência.

Em um grande projeto com várias equipes e constantes manutenções, import statics é um tanto quanto venenoso. Agora, eu acho legal isso:

out.println("Sem o System, uhuuu!");

[]s.

Paulo, por favor, explique-se nessas suas sugestões… Eu estou sinceramente interessado em entender seus motivos pra pensar assim! É só ódio de herança mesmo (por motivos que vão além da minha compreensão no momento) ou tem algo mais??

static imports é o tipo de coisa que ainda to tentando encontrar uma razão pra ter sido inserida na linguagem… tanta coisa mais importante pra se preocupar…

Concordo com o Paulo em relação à static e, principalmente, protected. Mas não concordo em relação a extends… herança cabe muito bem em alguns lugares - com certeza não em todos, mas é indispensável em muitos cenários.