Por que o Java tem métodos `void`?

/ Por que o Java precisa ter voidmétodos? Referência :

Qualquer método declarado nulo não retorna um valor.

Tanto quanto posso pensar, todo uso de voidseria melhor se retornássemos uma flag de status, o objeto que está sendo chamado ou null.

Isso tornaria cada chamada uma declaração que é atribuível e facilitaria os padrões do construtor e o encadeamento de métodos. Métodos que são chamados apenas para seus efeitos geralmente retornam um tipo booleano ou genérico Successou lançam uma exceção em caso de falha.

Como existe uma diferença entre "Esta função pode ter êxito ou falhar e é autoconsciente o suficiente para saber a diferença" e "Não há comentários sobre o efeito dessa função". Sem isso void, você verifica incessantemente os códigos de sucesso e acredita que está escrevendo um software robusto, quando na verdade não está fazendo nada disso.

1. Porque C tem um voidtipo e Java foi projetado para seguir muitas das convenções da família de idiomas C.
2. Existem muitas funções que você não deseja que retornem um valor. O que você vai fazer com "um Successtipo genérico "? De fato, os valores de retorno para indicar sucesso são ainda menos importantes em Java do que em C, porque Java possui exceções para indicar falha e C não.

A razão original pela qual a linguagem tem um voidtipo é porque, como em C, os criadores da linguagem não queriam complicar desnecessariamente a sintaxe da linguagem com procedimentos e funções como Pascal.

Essa foi a razão original.

Suas sugestões:

retornando um sinalizador de status

Isso é um não-não. Nós não usamos sinalizadores de status. Se algo der errado, nós o reportamos por meio de exceções.

o objeto que está sendo chamado

O estilo fluente de invocações é um desenvolvimento recente. Muitos dos programadores que estão muito felizes em usar fluentemente hoje em dia e reviram os olhos se tiverem que usar uma interface que não a suporta nem nasceram quando o Java foi criado.

retornando nulo

Isso forçaria você a declarar um método como retornando algo, quando na verdade ele não está retornando nada, portanto seria muito confuso para alguém que está olhando para uma interface tentando descobrir o que faz. As pessoas inevitavelmente inventariam alguma classe inútil que significa "sem valor de retorno", para que todas as funções que não têm nada a retornar possam retornar uma referência nula a essa classe. Isso seria desajeitado. Felizmente, existe uma solução para isso, é chamada void. E essa é a resposta para sua pergunta.

Alguns métodos, como o System.out.println, não retornam nada útil, mas são chamados exclusivamente para esse efeito colateral. voidé um indicador útil para o compilador e para o leitor de código que nenhum valor útil é retornado.

Retornar em nullvez de voidsignifica que você apenas obteria NullPointerExceptiono momento em que usar esse valor para qualquer coisa. Então você troca um erro de tempo de compilação por um erro de tempo de execução que é muito pior. Além disso, você teria que definir o tipo de retorno como Object, o que seria enganoso e confuso. (E o encadeamento ainda não funcionaria.)

Os códigos de status geralmente são usados ​​para indicar condições de erro, mas o Java possui exceções para essa finalidade.

thisNão é possível retornar de métodos estáticos.

Retornar um Successobjeto genérico não teria nenhum propósito útil.

Uma razão é que pode ser enganoso retornar algo que não seja, digamos null,. Exemplo:

O que deve Arrays.sort(a)retornar?

Se você argumenta que adeve ser retornado para que a chamada possa ser encadeada (que parece ser sua resposta a julgar pela sua pergunta), não fica mais claro se o valor de retorno é uma cópia do objeto original ou o próprio objeto original . Ambos são possíveis. E sim, você pode colocá-lo na documentação, mas é suficientemente ambíguo que você não deve criar a ambiguidade em primeiro lugar.

Por outro lado, se você argumenta que nulldeve ser retornado, isso levanta a questão de quais informações o valor de retorno possivelmente está fornecendo ao chamador e por que o programador deve ser forçado a escrever return nullquando não transmite informações.

E se você retornar algo totalmente absurdo (como o tamanho de a), isso tornará o uso do valor de retorno realmente confuso - pense em quanto mais confuso é dizer em int len = Arrays.sort(a)vez de int len = A.length!

Retornar um booleanque é sempre igual ao trueque você sugere, não é apenas inútil (o valor de retorno não traz informações), mas seria realmente enganoso. Na maioria das vezes, é melhor usar tipos de retorno que só confiram tanta informação quanto está realmente disponível - é por isso que em Java você tem booleanpara true/ falseem vez de retornar um intcom 4 bilhões de valores possíveis. Da mesma forma, retornar a booleancom dois valores possíveis, onde existe apenas um valor possível ("sucesso genérico"), seria enganoso.

Também acrescentaria sobrecarga de desempenho desnecessária.

Se um método é usado apenas para seu efeito colateral, não há nada para retornar e o tipo de retorno voidreflete exatamente isso. Erros raros em potencial podem ser sinalizados por meio de exceções.

Uma coisa que poderia ser melhorada seria criar voidum tipo real, como o de Scala Unit. Isso resolveria alguns problemas, como lidar com genéricos.

Java é uma linguagem relativamente antiga. E em 1995 (quando foi criado) e logo em seguida os programadores ficaram muito preocupados com a quantidade de tempo que um processo assumiu o controle do processador, bem como com o consumo de memória. Retornar nulo eliminaria alguns ciclos de clock e um pouco de consumo de memória de uma chamada de função, porque você não precisaria colocar o valor de retorno na pilha e não precisaria removê-lo posteriormente.

O código eficiente não devolve algo que você nunca usaria e, portanto, colocar o vazio em algo que tenha um valor de retorno sem sentido é uma prática muito melhor para se praticar do que retornar um valor de sucesso.

Eu li argumentos que sugerem que a segunda opção (retorno this) deve ser a abordagem em vez de void. Essa é uma boa idéia, mas a abordagem no estilo do construtor não era popular no momento em que o Java foi criado. Se fosse tão popular naquela época como agora, essa poderia ter sido a abordagem adotada. Retornar nullé uma péssima idéia da OMI. Eu gostaria que nullnem estivesse no idioma.

O problema agora é que, se um método retorna uma instância do seu próprio tipo, não está claro se é um novo objeto ou o mesmo. Freqüentemente não importa (ou não deveria), mas outras vezes importa. Suponho que o idioma possa ser alterado para retornar implicitamente thisaos métodos nulos. O único problema que posso pensar com isso no momento é que se o método fosse alterado posteriormente para retornar um novo objeto do mesmo tipo, não haveria avisos de compilação, mas talvez isso não seja um grande problema. O sistema de tipos atual não se preocupa com esses tipos de alterações agora. Como isso interage com a herança / interfaces precisaria de alguma consideração, mas permitiria que APIs antigas sem um estilo de construtor fossem facilmente chamadas como se fossem.

Outro aspecto:

Java é uma linguagem estática com recursos bastante rígidos. Isso significa que muitas coisas que seriam bastante abertas ou dinâmicas em outros idiomas (c / f Ruby, Lisp etc.) são estritamente determinadas.

Esta é uma decisão geral de design. O "porquê" é difícil de responder (bem, porque os designers da linguagem pensaram que seria bom!). O "para quê" é bastante claro: permite que o compilador detecte muitos erros, o que geralmente é um recurso muito bom para qualquer idioma. Em segundo lugar, torna relativamente fácil raciocinar sobre o idioma. Por exemplo, é relativamente fácil criar provas formais de correção na (subconjuntos) da linguagem Java; como comparação, isso seria praticamente impossível em uma linguagem dinâmica como Ruby et al.

Esse pensamento permeia a linguagem, por exemplo, a declaração forçada de possíveis exceções que um método pode lançar, o tipo separado de interfacevs. classpara evitar herança múltipla ambígua e assim por diante. Para o que é (uma linguagem imperativa estática do mundo real OOP, com forte foco no tratamento de erros em tempo de compilação), essas coisas são realmente bastante elegantes e poderosas. Eles se aproximam das linguagens teóricas (científicas) que são propositalmente criadas apenas para explorar alguns desses problemas do que qualquer outra linguagem do mundo real antes (naquele momento, lembre-se).

Assim. Ter um voidtipo estrito é uma mensagem clara: esse método não retorna nada, ponto final. É o que é. Substituí-lo pela aplicação para sempre retornar algo levaria a um comportamento muito mais dinâmico (como em Ruby, onde cada def tem sempre um valor de retorno explícito ou implícito), o que seria ruim para a provabilidade e o raciocínio; ou inchaço maciço usando algum outro mecanismo aqui.

(E, no entanto, Ruby (por exemplo) lida com isso de maneira diferente, e sua solução ainda é exatamente tão aceitável quanto a de Java, porque possui uma filosofia completamente diferente. Por exemplo, lança a provabilidade e a razoabilidade completamente fora da janela enquanto coloca um grande foco em expressividade extremamente alta do idioma.)