2010-09-13 26 views
5

Estoy buscando la convención de nomenclatura oficial en Java con respecto a los accessors.Java: convención de nomenclatura para accesors

He visto que, por ejemplo, la clase JPanel desaprobó el método size() a favor de getSize().

Pero en la clase ArrayList, el método es size().

Así que me pregunto si los accesadores deben llamarse getXXX() o xXX()?

Respuesta

11

Por lo general es una mala idea no utilizar la convención JavaBeans (captadores y definidores).
Son utilizados a través de la reflexión por muchos frameworks, en particular con EL donde a veces no puede acceder a sus campos sin los get get de derechos (dependiendo del sabor EL).

Por lo tanto, sus accesadores siempre deben llamarse getXxx() o isXxx() y setXxx().

size() en el marco de recopilación es un ejemplo de "falla" que puede molestar a los desarrolladores (ver enlace a continuación). La elección hecha por Josh Bloch y Neal Gafter para hacerlo más legible ahora hace que sea difícil de obtener en algunos contextos (EL).

Pero recuerde que la convención de JavaBeans no es la convención de nomenclatura de Java.


Recursos:

Sobre el mismo tema:

+3

(+1) Me sorprende que la página [* Naming * Conventions] (http://www.oracle.com/technetwork/java/codeconventions-135099.html#367) se titula "NO TITLE", heh. –

1

Para cualquier cosa que intente parecerse a un JavaBean, debería ser getXXX o isXXX. (No recuerdo si hasXXX también es válido para propiedades booleanas ... no estoy seguro).

Tiene sentido tratar un JPanel en forma de frijol, para diseñadores, etc., pero no como ArrayList.

Personalmente tiendo utilizar la forma getXXX sólo por coherencia, pero creo que lo anterior es el razonamiento implicado en el nombramiento de ArrayList 's.

0

En Eclipse la convención es definitivamente utilizar el patrón get. Las herramientas de automatización crean y manejan captadores buscando y escribiendo accesos de estilo get y set.

3

Con los métodos de consulta, siempre miro getXXX como algo que se proporciona en comparación con algo que se calcula. El método size() devuelve el tamaño de la colección que es un valor derivado, por lo que tiene sentido. Si tuviera getSize() mi suposición sería que de alguna manera podría establecer el tamaño (a través de un método de constructor o instalador).

+0

Haces un buen punto, pero diría que 'getSize()' tiene más sentido en comparación con 'size()' se puede considerar una propiedad (aunque sea virtual) de 'List' ya que siempre tiene un tamaño asignado . –

0

Yo prefiero el get/is/set -Convenio (especialmente para ValueObjects/DataObjects), no sólo porque son los JavaBeans especificación, pero a causa de los siguientes dos puntos

  1. El prefijo claro del método separa los métodos relacionados con la propiedad de los métodos 'lógicos'.
  2. Puede usarlo de fábrica con JSP y otros marcos que asuman esta denominación.
1

Ésta es sólo una addentum formativa a la respuesta de Colin HERBERT que, en mi opinión, es suficiente:

  • Accessor firmas de métodos Siempre debe ser similar public Type getProperty(). Además, los usuarios de acceso siempre deben devolver una copia del valor de la propiedad, no el valor en sí.
  • mutador firmas de método siempre debe ser similar public void setProperty(Type value)

combinación de un descriptor de acceso y una mutador le da una propiedad JavaBean. Los JavaBeans no se consideran inmutables por naturaleza, pero si desea que sean inmutables, debe usar la siguiente firma para el método del mutador: public YourJavaBean withProperty(Type value). Tenga en cuenta que esto siempre debe devolver una instancia de YourJavaBean completamente nueva con valores de propiedad copiados.

0

Siempre es mejor seguir los patrones setXXX y getXXX según la especificación JavaBeans. El método size() llamado así, puede ser porque solo está consultando el estado.

Cuestiones relacionadas