Quando é desejado para não implementar toString () em Java?
https://stackoverflow.com/questions/1161228
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Um desenvolvedor líder no meu projeto tomou a remeter para implementações como "cruft pura" toString do projeto () e está olhando para removê-los da base de código.
Eu já disse que isso significaria que todos os clientes que desejam exibir os objetos teria que escrever o seu próprio código para converter o objeto a corda, mas que foi respondida com "sim eles".
Agora, especificamente, os objetos neste sistema são elementos gráficos como retângulos, círculos, etc e a representação atual é a visualização x, y, escala, limites, etc ...
Então, onde é que a mentira multidão?
Quando você deve e quando não deve implementar toString?
Solução
Que mal que eles fazem? Por que removê-los se você os tem? Acho toString () extremamente útil quando emitindo declarações de depuração.
Pessoalmente, eu sempre err no lado de ter um método toString viável (). Tão pouco trabalho para escrever.
Outras dicas
Removendo bem escrito (ou mesmo a meio caminho decentemente escrito) toString () métodos é pura insanidade, IMO. Sim, eu sou muitas vezes demasiado preguiçoso para escrever estas (como muitas vezes os objetos não acabar tendo-los usado de qualquer maneira), mas eles são extremamente útil para ter.
Eu realmente não consigo pensar em uma boa razão para querer se livrar desses.
Eu sempre a certeza que minhas aulas implementado toString.
Ele fornece uma maneira simples de depurar o estado atual da classe quando estou depuração e quando estou registrando erros, posso incluí-lo em minhas mensagens de log.
Eu manteria as implementações toString(). Eles são de valor inestimável quando se trata de depuração, e eles podem fazer para uma boa texto alternativo para componentes gráficos.
Eu diria o contrário que toString () deve ser anulado criteriosamente. A implementação toString () padrão é muito informativo e basicamente inútil. Uma implementação boa toString () pode dar um programador uma vista muito útil do conteúdo do objecto de relance. Você não pode ter que colocar tudo lá dentro, mas pelo menos as coisas importantes. Eu acho que seu principal desenvolvedor deve ser realmente a codificação e adicionando funcionalidades ao invés de se preocupar com "cruft".
Eu só iria implementá-lo para objetos mais complexos, onde o código do cliente não se preocupa com os grão fino detalhes do estado do objeto, mas sim se preocupam com alguma mensagem compreensível, sentido tornando mais humano, que resume o que está acontecendo, estado sábio ...
Para tudo o resto, como JavaBeans, eu esperaria código de cliente para jogar meu objeto em um método ToStringBuilder ou similar, se ele precisa fazer a depuração de baixo nível.
ToStringBuilder.reflectionToString(myObject);
ou código de cliente deve apenas chamar getters de propriedade padrão e registrar a maneira que eles gostam ...
Em geral, toString() é muito bom. Em particular, é muito útil para depurar .
A implementação toString() não é sem custos e riscos . Como todo o código, implementações toString() deve ser mantida com o resto do código. Isso significa manter toString() em sincronia com campos de classe. Por exemplo, quando um campo é adicionado ou removido, toString() deve ser atualizado de forma adequada (você deve estar fazendo isso já por métodos como hashCode() e equals()).
Implementar incorre toString() riscos também. Por exemplo, suponha que duas classes em seu sistema têm referências a instâncias do outro (um link bidirecional), então uma invocação de toString() poderia levar a um estouro de pilha devido a recursão ilimitada como o toString() implementação em cada classe invoca a implementação toString() da outra classe.
Se o seu sistema tem um número significativo de métodos toString() out-of-sync, ou métodos que causam erros como estouros de pilha, então seu colega pode têm um ponto razoável. Mesmo em tal caso, gostaria de simplesmente comment-os métodos de buggy toString() e deixá-los no código. Cada método toString() poderia ser comentada e atualizado individualmente, conforme necessário no futuro.
Sempre gerar automaticamente toString () métodos para todos os meus POJOs, DTOs e / ou qualquer objeto que contém dados persistentes. Para propriedades internas privadas boas práticas de registro deve fazer o truque.
Lembre-se sempre para substituir em toString métodos senhas e outras informações sesitive com [Omitted] (ou algo similar de topo natureza secretam)
Bem, ele faz coisa stramge.
Eu não posso dizer toString () é muito útil. Para a apresentação terá outras ferramentas.
Mas toString () é bastante útil para a depuração, porque você pode ver o conteúdo de coleções.
Eu não entendo por que removê-lo se ele já está escrito
Eu acho que a resposta depende de como complicado o seu toString () métodos são, quanto trabalho de que necessitam para manter, e quantas vezes eles se acostumar. Supondo que você use toString () muitas vezes para registro e depuração que não faz muito sentido para remover esses métodos. Mas se eles são raramente usados ??e requerem muito trabalho para manter cada vez que algo muda em seu código, então não é, talvez, um argumento válido para se livrar de todos ou alguns do toString () métodos.
Você mencionou algo sobre clientes que necessitam para exibir esses objetos. Deste Eu estou supondo que o seu código é ou contém algum tipo de biblioteca ou API que outros desenvolvedores vão usar. Neste caso, eu recomendo que você manter toString útil () implementações. Mesmo se você não fizer um monte de logging e depuração, seus clientes pode e que vai certamente gostar de ter toString útil () métodos que eles não têm de escrever e manter-se.
+1 Mike C
Para além da sua utilidade para a depuração, o toString () é uma ferramenta valiosa para entender a perspectiva do autor classe da instância.
FWIW, se a saída dos difere toString do que você espera para ver (docs cortesia SPEC) você vai saber rightaway algo deu muito errado.
Pessoalmente, eu implementá-las quando eu vou objetos de uso em um JList, JTable, ou outra estrutura que usos toString () ou quando estou a depuração (sim, eclipse tem formatadores de depuração, mas toString () é mais fácil) .
Talvez você pode disparar de volta que muitas classes JDK tem toString (). eles devem ser removidos também? ;)
Eu diria que você deve implementar toString se isso é um caso esperado uso ou exigência, para exibir o objeto como uma representação string (tanto em toras, na consola, ou algum tipo de árvore de exibição).
Caso contrário, eu concordo com o desenvolvedor - cada vez que você mudar alguma coisa, o toString pode quebrar. Você pode ter que ter cuidado com valores nulos, etc.
Muitas vezes, porém, é de fato usado na depuração ou na exploração madeireira, por isso não é óbvio que deve ser deixado de fora em tudo.
Eu concordo com jsight que, se eles já estão escritas, e escrito decentemente, deixá-los em, pelo menos até que eles ficam no caminho (como você realmente adicionar um campo a uma classe).
Para fins de depuração, ninguém pode bater toString. É prático, tanto em um depurador, e em gravuras simples depuração. Certifique-se que exibe todos os campos que seus métodos equals e hashCode são baseados em, se você substituir as também!
Para exibição para os usuários finais, eu não iria usar toString, no entanto. Para isso, eu acho que é melhor para escrever um outro método, que faz a formatação adequada, e i18n se você precisa disso.
É de bom senso porque você sempre tem problemas com toStrings mostrando informações muito pouco ou muito.
Pode fazer sentido para a sua equipe para usar o ToStringBuilder em Jakarta Commons Lang em vez disso:
System.out.println("An object: " + ToStringBuilder.reflectionToString(anObject));
que examinará o objeto, e imprime os campos públicos.
Eu já disse que isso significaria que todos os clientes que desejam exibição os objetos teria que escrever o seu próprio código para converter o objeto para string, mas que foi respondida com "Sim, eles iriam".
Esta não é uma pergunta que pode ser respondida em isolamento ... você deve perguntar aos clientes (ou as pessoas que escrevem eles) o que eles acham da idéia. Se eu estava usando uma biblioteca Java e confiando em sua toString () sobrecargas para a depuração, eu estaria um pouco irritado se os desenvolvedores da biblioteca decidiu eliminá-los.
Para ser justo, disse desenvolvedor aqui, mas não desenvolvedor líder em qualquer sentido.
O problema original não é necessariamente sobre toString (), mas cerca de um segundo paramString método: "Com toda a sua concatenação e nulos valor verificação, paramString é um ímã bug."
http://code.google.com/p/ piccolo2d / questões / detalhes? id = 99
Eu definitivamente manter o toString () implementações, particularmente para fins de depuração. Como C desenvolvedor principalmente ++, eu gostaria que as coisas eram tão fáceis em C ++ como eles estão em Java a este respeito (sobrecarga de operador pode ser uma dor).
Se houver um problema com as implementações toString() existentes, o desenvolvedor deve resolver o problema. Dizendo que as implementações atuais são todos "cruft pura" e removê-los é fazendo ativamente danos, a menos que os métodos toString() existentes são uncommonly mal escrito.
Eu faria fortemente desencorajar o desenvolvedor de remover qualquer método toString() funcionando.
implementar sempre :) Como mencionado acima, é inestimável para depuração.
É bom para fins de depuração. Mas se você deseja exibir determinado objeto como uma string para o usuário final que você nunca deve usar toString () implementação, mas fornecer método personalizado para isso.
Assim, em relação
Eu já disse que isso significaria que todos os clientes que desejam exibição os objetos teria que escrever o seu próprio código para converter o objeto para string, mas que foi respondida com "Sim, eles iriam".
Eu concordo com o seu chefe de equipe. Se você deseja exibir objeto para qualquer implementação do cliente uso personalizado. Se você quiser usá-lo para fins de depuração usar toString ().
Embora os métodos toString() são muito útil para depurar classes de valor, pode-se argumentar que eles são não é útil para classes de entidade .
eu percebi que eu pesar com uma perspectiva mais moderna, dado que esta questão é agora quase 10 anos de idade.
toString é obviamente útil para depurar - você precisa olhar mais longe do que todas as outras respostas aqui que atestam a isso -. Mas informações de depuração não é lógica do negócio
Ter um método toString em cada classe é desordem visual que obscurece o comportamento útil da classe. Nós também precisa se lembrar de mantê-lo - manualmente ou regenerar o método da nossa IDE -. Cada vez que mudar os campos de classe
Então, o que podemos fazer para resolver esses problemas sem remover o método completamente? A resposta é gerar automaticamente . do Projeto Lombok @ToString anotação pode gerar automaticamente um método toString para você em tempo de compilação que inclui qualquer combinação de campos que você escolher.
uso de amostra básica:
@ToString
public class Foo {
private int i = 0;
}
que se tornará equivalente ao seguinte em tempo de compilação:
public class Foo {
private int i = 0;
public String toString() {
return "Foo(i=" + this.i + ")";
}
}
Estamos recebendo uma ConcurrentModificationException jogado para fora de um dos nossos métodos toString (), então há um problema ocasional. É claro que é a nossa própria culpa por não torná-lo sincronizado.
