Para un campo booleano, ¿cuál es la convención de nomenclatura para su captador / definidor?

178

P.ej.

boolean isCurrent = false;

¿Cómo se llama su captador y definidor?

user496949
fuente
2
Supongo que se refiere a JavaBeans, en cuyo caso la respuesta de @Jigar Joshi es correcta. Sin embargo, si está preguntando acerca de getter / setters genéricos, la única convección es que los métodos contienen el nombre del campo y el getter no toma argumentos y devuelve un valor, el setter toma un argumento y no devuelve ningún valor o devuelve el objeto en sí. vea Buffer como un ejemplo de otro enfoque para getter / setters.
Peter Lawrey

Respuestas:

254

Supongamos que tienes

boolean active;

El método de acceso sería

public boolean isActive(){return this.active;}

public void setActive(boolean active){this.active = active;}

Ver también

Jigar Joshi
fuente
9
¿Podría señalar la sección de convenciones de código de Sun donde los nombres de captadores booleanos están específicamente cubiertos? No pude encontrarlo.
Konstantin Pelepelin
44
Tengo un archivo booleano llamado hasCustomName, ¿ahora qué debo nombrar para sus métodos getter y setter ? Es setHasCustomName[setter]y hasCustomName[getter]bueno?
Hadi
@Hadi solo nombra tu variable "customerName" y genera getter n setter para ella. Getter y setters esperados son public boolean isCustomerName(){return this.customerName;} public void setCustomerName(boolean customerName){this.customerName= customerName;}
Assegd
1
¿Cómo pasamos del nombre personalizado al nombre del cliente? ;)
Kartik Chugh
1
@Assegd Nombrarlo "customerName" o "customName" es confuso y no denota que es booleano. Al ver la variable, espero que contenga un nombre. En este caso, debería llamarse "hasCustomName" IMO.
Nathan
83

http://geosoft.no/development/javastyle.html#Specific

  1. is El prefijo debe usarse para variables booleanas y métodos.

    isSet` isVisible` isFinished` isFound`isOpen

Esta es la convención de nomenclatura para métodos booleanos y variables utilizadas por Sun para los paquetes principales de Java. El uso del prefijo is resuelve un problema común de elegir nombres booleanos incorrectos como status o flag. isStatus o isFlag simplemente no encaja, y el programador se ve obligado a elegir nombres más significativos.

Los métodos Setter para variables booleanas deben tener un prefijo establecido como en:

void setFound(boolean isFound);

Hay algunas alternativas al prefijo is que se ajusta mejor en algunas situaciones. Estos son prefijos has, can y should:

boolean hasLicense(); 
boolean canEvaluate(); 
boolean shouldAbort = false;
Narayan
fuente
77
Entonces, si existe la propiedad booleana hasData, ¿cómo sería el setter? Sin duda, me setData(bool hasData)parece terriblemente mal ...
Franz B.
77
@FranzB. Usaría setHasData (...)
user362178
2
Para aquellos que quieran sigue JavaBeans specifcation, parece que has, can, shouldprefijos no forman parte de la especificación. Consulte JavaBeans Specification 1.01 sección 8.3.
VCD
@ Andrew Hola. Cuando uso el prefijo 'is' en mi variable y envío el valor de esa variable desde mi archivo js en los datos, siempre me da el valor como falso. Y si elimino el prefijo 'es', entonces funciona absolutamente bien. ¿Cuál puede ser la razón de eso? Gracias por adelantado.
Me_developer
1
El setter es sencillo, para el getter que tuve que usar, de lo boolean isIsCurrent(){...}contrario, el marco utilizado para deserializar el objeto se quejaba getter not found for property isCurrent.
Maurizio Lo Bosco
67

Para un campo llamado isCurrent, el nombre correcto de getter / setter es setCurrent()/ isCurrent()(al menos eso es lo que piensa Eclipse), lo cual es muy confuso y puede rastrearse hasta el problema principal:

Su campo no debe ser llamado isCurrenten primer lugar. Is es un verbo y los verbos son inapropiados para representar el estado de un Objeto. Use un adjetivo en su lugar, y de repente sus nombres getter / setter tendrán más sentido:

private boolean current;

public boolean isCurrent(){
    return current;
}

public void setCurrent(final boolean current){
    this.current = current;
}
Sean Patrick Floyd
fuente
44
¿Qué pasa si el booleano no es primitivo? Si es booleano, ¿debería ser un get o es?
Arun
2
No, dicho método podría devolver nulo, lo que provocaría una NullPointerException. Pero trataría de evitar regresar a Boolean en primer lugar
Sean Patrick Floyd el
3
@Arun Creo que debería establecerse / get en su lugar si set / es porque Boolean es un objeto en lugar de primitivo, porque tiene 3 estadísticas, falso, verdadero o nulo.
Al-Mothafar
1
IntelliJ usa de manera predeterminada el getprefijo al recuperar un Booleanvs ispara unboolean
jocull
1
@jocull y ese es el comportamiento correcto, de acuerdo con la especificación JavaBeans
Sean Patrick Floyd
6

Yo creo que sería:

void setCurrent(boolean current)
boolean isCurrent()
miku
fuente
1
Me gusta esa convención, pero las convenciones realmente no importan. Lo más importante es seguir con el que elegiste.
Clement Herreman
44
Las convenciones de @Clement son importantes cuando confía en las herramientas que utilizan estas convenciones. JavaBeans es una convención con amplio soporte en muchas bibliotecas (JSP / JSF / Spring / Groovy solo por nombrar algunas). Romper las convenciones significa romper la forma en que funcionan estas bibliotecas.
Sean Patrick Floyd
1
@Sean Right, a excepción del marco que se basa en convenciones sobre la configuración. En este caso, el marco impone las convenciones, por lo que no elige nada. Buen comentario
Clement Herreman
5

¿Quizás es hora de comenzar a revisar esta respuesta? Personalmente me gustaría votar a favor setActive()y unsetActive()(alternativas pueden ser setUnActive(), notActive(), disable(), etc, dependiendo del contexto) ya que "setActive" implica que activarlo en todo momento, que usted no lo hace. Es una especie de contador intuitivo decir "setActive" pero en realidad eliminar el estado activo.

Otro problema es que no puede escuchar específicamente un evento SetActive de una manera CQRS, necesitaría escuchar un 'setActiveEvent' y determinar dentro de ese oyente si realmente se activó o no. O, por supuesto, determinar a qué evento llamar cuando se llama, setActive()pero eso va en contra del principio de Separación de preocupaciones.

Una buena lectura sobre esto es el artículo de FlagArgument de Martin Fowler: http://martinfowler.com/bliki/FlagArgument.html

Sin embargo, vengo de un fondo PHP y veo que esta tendencia se adopta cada vez más. No estoy seguro de cuánto vive esto con el desarrollo de Java.

Christian Vermeulen
fuente
-1
private boolean current;

public void setCurrent(boolean current){
    this.current=current;
}

public boolean hasCurrent(){
    return this.current;
}
Mkne
fuente
3
tiene corriente que? Creo que se hasusa para BO o un servicio de este tipo con algún procesamiento, mientras que para POJO lo es is. y agregue alguna descripción sobre su respuesta.
Al-Mothafar
-3
Setter: public void setCurrent(boolean val)
Getter: public boolean getCurrent()

Para booleanos también puedes usar

public boolean isCurrent()
Suraj Chandran
fuente
11
Porque el OP plantea una pregunta sobre valores booleanos. Un getter con el prefijo 'get' es (léase: debería) nunca usarse para valores booleanos.
Harold
-4

Como setter, ¿qué tal:

// setter
public void beCurrent(boolean X) {
    this.isCurrent = X;
}

o

// setter
public void makeCurrent(boolean X) {
    this.isCurrent = X;
}

No estoy seguro de si estos nombres tienen sentido para los hablantes nativos de inglés.

amekusa
fuente
1
Realmente no tienen sentido
Yannjoel
Pero suena fonéticamente tal vez prometedor con algunos atributos :)
seba.wagner