Existem convenções de pedido de método Java? [fechadas]

159

Eu tenho uma classe grande (40 ou mais métodos) que faz parte de um pacote que enviarei como trabalho de curso. Atualmente, os métodos são bastante desordenados em termos de utilidade pública / privada etc. e eu quero ordená-los de uma maneira sensata. Existe uma maneira padrão de fazer isso? Por exemplo, normalmente os campos são listados antes dos métodos, os construtores são listados antes dos outros métodos e os getters / setters duram; e os métodos restantes?

java methods conventions

— Fredley
fonte

Observe também que, ao trabalhar com códigos como este, a maioria dos IDEs permite que você veja a definição do que está abaixo do cursor automaticamente. Isso significa que você não precisa fazer nada além de olhar.

— Thorbjørn Ravn Andersen

Se você tem 40 métodos em uma única classe - você está fazendo errado

— Ben

132

Algumas convenções listam todos os métodos públicos primeiro e depois todos os privados - isso significa que é fácil separar a API da implementação, mesmo quando não há interface envolvida, se você entende o que quero dizer.

Outra idéia é agrupar métodos relacionados - isso facilita a identificação de costuras onde você pode dividir sua classe grande existente em várias menores e mais direcionadas.

— Jon Skeet
fonte

1

+1. Eu prefiro classificar por visibilidade. Vergonha Eclipse não pode fazer isso automaticamente (ele vai sempre grupo todos os construtores juntos e todos os métodos em conjunto.)

— finnw

16

@finnw, envie um relatório de erro. Sabe-se que coisas mais estranhas foram implementadas a partir daí.

— Thorbjørn Ravn Andersen

3

@ Ben: Minha experiência é que qualquer "nunca" terá exceções.

— Jon Skeet

1

@JonSkeet em alguns casos, onde as convenções de pedidos não são mais relevantes, por exemplo, classes de teste. Não escrever código incorreto é melhor aconselhar do que como organizar código incorreto.

— Ben

1

@ Ben: Acho que teremos que concordar em discordar. Eu escrevi o código onde há muito naturalmente muitos membros, sem violar qualquer separação de interesses etc.

— Jon Skeet

121

Variáveis de classe (estáticas): primeiro as variáveis de classe pública, depois as protegidas e depois as privadas.
Variáveis de instância: primeiro público, depois protegido e depois privado.
Construtores
Métodos: esses métodos devem ser agrupados por funcionalidade e não por escopo ou acessibilidade. Por exemplo, um método de classe privada pode estar entre dois métodos de instância pública. O objetivo é facilitar a leitura e a compreensão do código.

Fonte: http://www.oracle.com/technetwork/java/codeconventions-141855.html

— Michael
fonte

4

Esta é de 15 anos e provavelmente um pouco desatualizado com o aparecimento de IDEs modernas ...

— assylias

16

@assylias: IMO, a legibilidade é independente do IDE. Manter o público antes do privado geralmente é melhor.

— Saurabheights

40

O link mais preciso para «Convenções de código»: «Declarações de classe e interface»

— Timofey Gorshkov
fonte

8

+1, afaik - este é o ÚNICO post que realmente responde à pergunta. SIM, existe uma ordem padrão ditada pela Oracle e Sun: 1. comentário público, 2. classe, 3. comentário interno, 4. dados estáticos, 5. dados da instância, 6. ctors, 7. métodos e dentro de cada grupo de seção logicamente, não por acessibilidade.

— John Henckel #

@VadimKirilchuk «Internet Archive» caiu…

— Timofey Gorshkov

1

oracle.com/technetwork/java/codeconvtoc-136057.html

— Elder Geek

15

Não tenho certeza se existe um padrão universalmente aceito, mas minhas próprias preferências são;

construtores primeiro
métodos estáticos a seguir, se houver um método principal, sempre antes de outros métodos estáticos
métodos não estáticos a seguir, geralmente na ordem da significância do método seguido por quaisquer métodos que ele chamar. Isso significa que métodos públicos que chamam outros métodos de classe aparecem na parte superior e métodos privados que não chamam outros métodos geralmente acabam na parte inferior
métodos padrão como toString, equalse hashcodepróximo
getters e setters têm um lugar especial reservado na parte inferior da classe

— Qwerky
fonte

Eu realmente prefiro os construtores por último, porque um construtor corretamente escrito deve fazer muito pouco além de atribuir seus argumentos às propriedades.

— GordonM

@GordonM Por que você acha isso? Eu chegaria ao ponto de argumentar que o inverso é verdadeiro. Você deve sempre pensar na API mais limpa para suas classes. E que muitas vezes não é a maneira como eles são armazenados em, por isso muitas vezes fazer um pouco de processamento para o alívio do chamador dessa carga

— Neuron

@GordonM Eu não estou falando sobre efeitos colaterais. Portanto, nenhuma alteração nas listas que foram aprovadas ou algo parecido. Só de passagem e definir valores requer que a classe lhe diz muito sobre a sua implementação, o que não deve ser o caso

— Neuron

@LonelyNeuron Não tenho muita certeza do que você está dizendo aqui, mas parece que você está dizendo que o construtor deve fazer muito trabalho de configuração além de atribuir seus argumentos ao estado interno. Definitivamente, isso está errado, porque significa que as coisas estão acontecendo por "mágica". Uma chamada para new Thing()deve resultar apenas em uma nova Coisa instanciada. Isso não deve resultar na abertura de conexões com o banco de dados, na

— gravação de

@LonelyNeuron Ter dependências em um construtor não diz nada sobre a implementação da classe, a não ser quais são suas dependências. Isso é bom, não ruim.

— GordonM

12

40 métodos em uma única classe é um pouco demais.

Faria sentido mover parte da funcionalidade para outras classes com nome adequado. Então é muito mais fácil entender.

Quando você tem menos, é muito mais fácil listá-las em uma ordem de leitura natural. Um paradigma frequente é listar as coisas antes ou depois de você precisar, na ordem em que você precisar.

Isso geralmente significa que main()vai por cima ou por baixo.

— Thorbjørn Ravn Andersen
fonte

1

você está tão certo - este não é um problema de ordenação

— kostja

4

Você nem sempre tem uma escolha, por exemplo, se estiver implementando uma interface com vários métodos.

— finnw

5

Esta é uma atividade Android, por isso há muitos que simplesmente não pode ir em qualquer outro lugar, onPause(), onResume()etc., bem como todos os meus OnClickListenercampos, que, apesar de serem campos, não se parecem ou se comportam como eles por isso é sensato listá-los separadamente.

— fredley

@finnw, as classes abstratas são agradáveis e utilizáveis para esse fim.

— Thorbjørn Ravn Andersen

11

Minha "convenção": estática antes da instância, pública antes da privada, construtora antes dos métodos, mas método principal na parte inferior (se presente).

— eljenso
fonte

2

Além disso, o eclipse oferece a possibilidade de classificar os alunos para você, se por algum motivo você os misturou:

Abra seu arquivo de turma, vá para "Origem" no menu principal e selecione "Classificar membros".

retirado daqui: Métodos de classificação no Eclipse

— Stephan Richter
fonte

1

Você está usando o Eclipse? Nesse caso, eu continuaria com a ordem de classificação padrão de membros, porque provavelmente é mais familiar para quem lê seu código (embora não seja minha ordem de classificação favorita).

— finnw
fonte