Por que os nomes de arquivos em Java são iguais aos do nome da class pública?

Em Java, o nome do arquivo deve ser o mesmo que o nome da public class contida nesse arquivo. Por que isso é uma limitação? Que finalidade serve?

Java tinha uma abordagem interessante – onde dar a um programador uma opção só pode degradar a experiência de programação, remova a escolha.

Eles fizeram isso em alguns lugares. Nomes de arquivos e pacotes, com certeza, mas também não permitindo múltiplas classs públicas em um arquivo (nunca boas), não permitindo que você divida classs entre arquivos (Droga, difícil de trabalhar!), Etc.

Eu realmente gostaria que eles tivessem ido mais longe. Não há razão para variables ​​públicas – nunca precisei de uma, nem jamais vi uma situação em que algum programador inteligente pensasse que era necessário e estava realmente certo.

Eu também não me importaria de ver limitações de tamanho de método / class, mas isso poderia ficar incompleto (poderia ser facilmente implementado por verificadores de código, o problema é que as empresas que mais precisam de ajuda são aquelas que não sabem que precisam ajudar e, portanto, não use ferramentas como verificadores de código).

Isso não é coisa que importa para a maioria das pequenas equipes, mas quando sua equipe cresce e tem vários sites com consultores da Índia, China e vários outros lugares em todo o mundo, você começará a apreciar a inflexibilidade.

Em resposta ao comentário de setters / getters:

Os Java beans eram uma abominação criada pela Borland para hackear sua GUI, depois adaptada para Java.

Idéia horrível – uma distração da programação OO – Getters e setters A) mostram muito da sua implementação e B) fazem você pensar em termos de operação em dados de outro object ao invés de pedir ao outro object para executar uma operação para você. Bad hack para pessoas que ainda não podem pensar em OO.

Os getters são necessários ocasionalmente, mas não devem ser adicionados, a menos que sejam absolutamente inevitáveis.

Setters devem ser evitados a todo custo. Se você realmente precisar modificar externamente o estado depois que um object for construído, tente usar o padrão do construtor e proteja seus setters de serem chamados após qualquer operação ter sido executada.

Obviamente, existem exceções para tudo, e muitos “Getters” são na verdade lógica de negócios de objects críticos, como String.length (), que seriam necessários independentemente de como String foi implementado e nem mesmo implementados apenas retornando uma propriedade – uma ótima caso de um “Getter”, se você quiser chamá-lo assim.

Eu estava prestes a dizer que é simplesmente uma obrigação . Mas eu olhei para o JLS , e não é tão rigoroso. Do ponto de vista do JLS, é deixado ao compilador escolher se deseja definir tal restrição ou não.

Praticamente falado – os compiladores comuns têm essa restrição e, como já foi explicado, é muito mais fácil para o compilador encontrar uma unidade de compilation ou um classloader para localizar um arquivo de class com essa restrição em vigor.

Para ser mais específico, o nome do arquivo tem o mesmo nome que o nome da class pública naquele arquivo. qual é a maneira de dizer à JVM que este é o ponto de input para você.

É apenas a convenção definida pela Sun, os fabricantes de Java.
O objective é organização; A razão é que todos os que codificam em Java terão uma maneira consistente de nomear arquivos.

Cada class pública deve estar em um arquivo no qual o nome do arquivo corresponde ao nome da class e um pacote no qual o nome do pacote representa a estrutura do diretório, gravada no formato pontilhado (barras se transformam em pontos, como com / example / app se torna com.example.app).

Essa convenção não é aleatória. O compilador tem que ser capaz de encontrar os arquivos de origem e o carregador de classs deve ser capaz de encontrar a implementação. A correspondência de nomes de pacotes e nomes de classs torna isso realmente simples e, mais importante, rápido.

Esta convenção não se aplica a classs não públicas. Isso ocorre porque as classs não públicas têm uma visibilidade muito limitada e só podem ser usadas no pacote em que estão definidas. Assim, em ambos os casos, o compilador e o ambiente de tempo de execução já localizaram os arquivos corretos.

P. “Então, como funciona no caso de C ++, onde não existe tal restrição?”

A. Não funciona. Você deve ter um makefile. Você não precisa de um em Java.

É útil para localizar a class. Suponha que diferentes nomes de arquivos sejam permitidos e, se você criou uma instância de uma class, o compilador deve procurar a class em todos os arquivos, se os nomes dos arquivos forem os mesmos da class, o desempenho de localizar e usar a class é aumentou. Suas também podem ser outras razões.

Contanto que não seja pública, uma class pode ter um nome diferente do nome do arquivo . A class também pode ter o método principal. O arquivo de class será gerado com o nome da class, mas não com o nome do arquivo de origem. O nome da class deve ser usado para executá-lo.

O motivo é: a class padrão é pacote private, assim o javac não precisa encontrar este arquivo de origem para compilar algum outro programa java de fora do pacote.