Nombrar un campo booleano que es un verbo

14

En Java, por convención getter y setter para campos booleanos serán isField()y setField(). Esto funciona perfectamente bien con los nombres de campos que son adjetivos como active, visible, closed, etc.

Pero, ¿cómo nombro un campo que tenga el significado de un verbo, como haveChildren? Agregue "_ing" al verbo ( ), ¿tal vez?havingChildren

Para aclarar, no tengo control de los nombres de los métodos (getter y setter) ya que son generados automáticamente por el IDE. Entonces, lo que necesito es un nombre de campo apropiado para que cuando el IDE genere un captador para él, tenga sentido. Por ejemplo, hasChildrenes un nombre de campo perfecto, pero cuando el IDE genera el captador para el campo, sería isHasChildren. ¿Cómo puedo solucionar esto?

java naming

— dnang
fuente

3

Si este es un campo bool, parentfuncionaría.

— Yannis

2

Si puede salirse con la suya invirtiendo el significado, 'sin hijos' sería la solución.

— Kilian Foth

3

Parece un poco tonto tener que pasar por alto el nombre de un campo para evitar un problema gramatical causado por el IDE. De todos modos, aquí hay algunas sugerencias adicionales, aunque creo que las que ya han dado otros son mejores: isAllowedChildren, isNotEmpty, isContainer, isLeaf,

— Aprendiz del Dr. Wily

sin hijos parece ser el camino a seguir. El problema con el padre es que ya tengo un campo padre para contener la referencia al objeto padre. Creo que lo que necesito es una regla general para convertir todos los verbos en adjetivos para campos booleanos.

— Dnang

1

Estoy de acuerdo con @dnhang en que no debe permitir que un IDE dicte cosas como esta. Elegir nombres de variables y métodos es importante para que su código sea legible, en qué IDE está escrito debe ser irrelevante.

— Digitalex

11

Respuesta corta:

Los nombres de los métodos no se supone que reflejan la implementación interna, sino el comportamiento esperado.

Respuesta larga:

haveChildren()debe ser nombrado hasChildren().

Tampoco veo hasChildren()que sea necesariamente el captador de un miembro de clase booleana. Supongo que tal método descubriría si un miembro de tipo Collectionestá vacío o no .

El nombre predeterminado que un IDE da a los captadores y establecedores generados no se supone que sea una ley establecida en piedra.

Otro punto: las interfaces tienen nombres para los métodos aún por implementar.

Si se supone que los nombres de los métodos reflejan la implementación interna, ¿cómo podría alguien diseñar una interfaz? Las interfaces no tienen una implementación ni saben de antemano qué harán los implementadores bajo el capó.

Tomemos por ejemplo la Iteratorinterfaz en Java.

Cuando implementa Iterator, incluso cuando tiene un miembro booleano llamado next, no se supone que cambie el nombre hasNext()a isNext()o isHavingNext(). Ese es un detalle de implementación. De hecho, lo he implementado Iteratory lo que hago es tener un miembro del tipo de lo que sea que mi clase tenga una lista, llamada next(no booleana). hasNext()Luego regresa next!=null.

Además, mira esto:

class patient {
      private boolean pulse;
      private boolean breaths:
      public boolean isDead(){ return (!pulse & !breaths);}
}

Tenga en cuenta que isDead()no es getter normal.

Tome las herramientas de productividad de IDE por lo que son.

— Tulains Córdova
fuente

3

Sugeriría cambiar el nombre del campo a parentpara que el getter sea isParenty setter sea setParent.

También puede probar childPresentpara el nombre de la variable y isChildPresent, y setChildPresentcomo el getter y setter.

— Thirumalai Parthasarathi
fuente

1

La misma idea que el comentario de Yannis anterior, pero el problema es que ya tengo un parentcampo para contener la referencia al objeto padre. Creo que lo que necesito es una regla general para convertir todos los verbos en adjetivos para campos booleanos.

— Dnang

0

Podrías poner doesantes del verbo. Tal como doesHaveChildrenen su ejemplo que proporcionó. O tal vez shouldHaveChildrendependiendo del contexto.

— miguel.martin
fuente

1

El problema es que no tengo control del nombre del método porque el captador y el definidor son generados automáticamente por el IDE (por ejemplo, Eclipse).

— Dnang

1

¿Solo cambia el nombre del método (s)? Agregue una combinación de teclas para cambiar el nombre de los métodos (si aún no tiene uno).

— miguel.martin

@dnhang si es su código, puede llamar a los métodos como desee, independientemente de cómo los llame el IDE cuando se genere automáticamente.

— Richard

1

@ miguel.martin Una razón por la que no querrías hacer esto es Java-beans. La suposición de isSomethinges parte de esa especificación y se hacen muchas suposiciones en torno a ella, para bien o para mal, ir en contra de esto doesSomethingpuede romper las cosas de maneras no tan obvias, lo que lleva a errores.

0

La pregunta es perfectamente razonable. A veces, cambiar el nombre del método generado automáticamente no es suficiente. Ejemplo: se espera que los beans gestionados JSF tengan isXyz()como método getter de una boolean xyzpropiedad.

Estoy de acuerdo con BlackPanther, que sugiere cambiar el nombre del campo parenty usarlo isParentcomo nombre del método. Según el principio de ocultación de información, la legibilidad de los métodos getter y setter es más importante que la del atributo.

— Paulo Merson
fuente