Ubicación preferida del método main() en el archivo de clase Java

Question

Cuando se trata de ordenar/secuenciar métodos en la clase java. ¿Dónde espera/prefiere ver el método main()?

• en la parte superior antes de cada campo (al usuario el estrés de su existencia y la fuerza él para usarlo)
• en la parte inferior (para permitir al usuario ver los campos primero y después de eso descubrir principal)
• después de c -tor
  o ....

Por favor, comparta sus ideas, esta es una pregunta estilística/filosófica. Por favor no sugiera mantener main() en un archivo separado solo.

Answer 1

Siempre lo he puesto al final, porque así es como lo hacen en C. "Tradición". Que puede no ser tan bueno de una razón. :-)

Answer 2

Sun Microsystems publicó sus convenciones de código para el lenguaje de programación Java hace muchos años y muchas organizaciones lo siguen en diversos grados.

En this section sugieren poner métodos al final de un archivo. Y como ya sabe, main es "solo otro método", aunque es un método de clase en lugar de un método de instancia.

Si bien nadie te obliga a seguir las convenciones de Sun, puede haber una ligera ventaja en permanecer cerca de ellas, ya que hay un cierto grado de familiaridad con ella. La mayoría (si no todas) de las bibliotecas estándar JDK lo seguirán.

Esto es en mi humilde opinión una buena razón para ir con el último método de métodos. En cuanto a la colocación de main entre los métodos, ponerlo primero o último funcionaría. Si lo encuentras "especial" de alguna manera, entonces ponlo muerto último en el archivo.

Answer 3

Estos son sólo mis pensamientos:

main() es un método estático no relacionado con instancias de objetos. Sabemos que existe como un punto de entrada, que hace que nuestro programa/clase sea ejecutable.

El problema es que en Java, todo (pero primitivos) es un objeto, por lo que main() debe declararse en alguna clase en alguna parte. El código que un método estático puede ejecutar está más relacionado con la configuración del programa para su ejecución y la delegación de nuestra lógica comercial (objetos que realmente hacen algo) para ejecutar la aplicación. Como tal, su preocupación es distinta del resto de nuestra clase (que define algunos datos y comportamientos que estamos tratando de encapsular).

main() realmente no pertenece a los datos y el comportamiento de nuestras clases diarias, ya que dudo que cada clase necesite ser ejecutable por sí misma. La preocupación de main() es ejecutar nuestro programa. Como tal, debe declararse fuera de nuestros objetos comerciales, en un módulo del proyecto relacionado con el lanzamiento/ejecución de la aplicación. Entonces, como podría estar adivinando, le propongo exactamente lo que ha dicho que no sugiera: manténgase separado de sus clases y su lógica tanto como sea posible, y solo defínelo en el contexto de un punto de entrada a su aplicación.

En cuanto a la ubicación dentro de un archivo en sí, realmente no creo que importe, siempre y cuando sea obvio que el código en ese archivo se refiere a la configuración y ejecución del programa.

Answer 4

Supongo que no sistemáticamente colocas un método main() en cada clase que escribas (en este caso posterior, tienes que imaginarte para escribir pruebas de unidad en su lugar).

Siempre que su clase contenga un método main(), al igual que el punto de entrada de su aplicación, esta clase no debería tener ningún otro comportamiento que no sea la inicialización de la aplicación. Esta buena práctica se llama "Separación de preocupaciones": una clase = una responsabilidad.

Si este es el caso, no deberías tener tantos métodos en tu clase. Personalmente, siempre clasifico el método por importancia: los métodos más importantes/útiles/centrales están por encima de todos los demás métodos, que no agregan ningún trabajo real (los setters y getters son de ese tipo para mí).

De esta manera, el lector tiene acceso a la información más importante primero.

Por supuesto, la codificación utilizando Java Convention, que recomiendo, implica que primero declare sus campos de clase, antes de declarar sus métodos.