Nomeando um campo booleano que é um verbo

13

Em Java, por convenção, getter e setter para campos booleanos serão isField()e setField(). Isso funciona perfeitamente bem com nomes de campos que são adjetivos como active, visible, closed, etc.

Mas como nomeio um campo com significado de verbo, como haveChildren? Adicione "_ing" ao verbo ( ), talvez?havingChildren

Para esclarecer, não tenho controle dos nomes dos métodos (getter e setter), pois eles são gerados automaticamente pelo IDE. Então, o que eu preciso é de um nome de campo apropriado para que, quando o IDE gerar um getter para ele, faça sentido. Por exemplo, hasChildrené um nome de campo perfeito, mas quando o IDE gerar o getter para o campo, ele seria isHasChildren. Como eu resolvo isso?

java naming

— dnang
fonte

3

Se este for um campo bool, parentfuncionaria.

— yannis

2

Se você se safar da inversão do significado, "sem filhos" seria o suficiente.

— Kilian Foth

3

Parece meio bobo ter que passar por obstáculos em relação ao nome de um campo para evitar um problema gramatical causado pelo IDE. Independentemente disso, aqui estão algumas sugestões adicionais, embora eu acho que as já dadas por outros são melhores: isAllowedChildren, isNotEmpty, isContainer, isLeaf,

— do Dr. Wily Apprentice

sem filhos parece ser o caminho a percorrer. O problema com o pai é que eu já tenho um campo pai para armazenar a referência ao objeto pai. Eu acho que o que eu preciso é de uma regra geral para converter todos os verbos em adjetivos para campos booleanos.

— dnang

1

Concordo com o @dnhang que você não deve deixar um IDE ditar coisas como esta. Escolher nomes de variáveis e métodos é importante para tornar seu código legível, em que IDE ele está escrito deve ser irrelevante.

— Digitalex

10

Resposta curta:

os nomes de métodos não são supostos para refletir a implementação interna, mas o comportamento esperado.

Resposta longa:

haveChildren()deve ser nomeado hasChildren().

Também não vejo hasChildren()como necessariamente o responsável por um membro da classe booleano. Eu acho que esse método descobriria se um membro do tipo Collectionestá ou não vazio.

O nome padrão que um IDE atribui aos getters e setters gerados não é suposto ser uma lei imutável.

Outro ponto: as interfaces têm nomes para métodos ainda a serem implementados.

Se os nomes dos métodos fossem supostos para refletir a implementação interna, como alguém seria capaz de projetar uma interface? As interfaces não têm uma implementação nem sabem de antemão o que os implementadores farão sob o capô.

Tomemos, por exemplo, a Iteratorinterface em Java.

Quando você implementa Iterator, mesmo quando você tem um membro booleano nomeado next, não é possível renomear hasNext()para isNext()ou isHavingNext(). Esse é um detalhe de implementação. Na verdade, eu implementei Iteratore o que faço é ter um membro do tipo de que minha classe possui uma lista, nomeada next(não um booleano). hasNext()então retorna next!=null.

Veja também:

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

Observe que isDead()não é um getter normal.

Leve as ferramentas de produtividade dos IDEs para o que são.

— Tulains Córdova
fonte

3

Sugiro renomear o campo para parentpara que o getter seja isParente o setter seja setParent.

Você também pode tentar childPresento nome da variável isChildPresente setChildPresentcomo getter e setter.

— Thirumalai Parthasarathi
fonte

1

Mesma idéia do comentário de Yannis acima, mas o problema é que eu já tenho um parentcampo para armazenar a referência ao objeto pai. Eu acho que o que eu preciso é de uma regra geral para converter todos os verbos em adjetivos para campos booleanos.

— dnang

0

Você pode colocar doesantes do verbo. Como doesHaveChildrenno seu exemplo que você forneceu. Ou talvez shouldHaveChildrendependendo do contexto.

— miguel.martin
fonte

1

O problema é que não tenho controle do nome do método porque o getter e o setter são gerados automaticamente pelo IDE (por exemplo, Eclipse).

— dnang

1

Apenas renomeie o (s) método (s)? Adicione um atalho de teclado para renomear métodos (se você ainda não o tiver).

— miguel.martin

@dnhang, se for o seu código, você pode chamar os métodos como quiser, independentemente do que o IDE os chama quando gera automaticamente.

— Richard

1

@ miguel.martin Uma razão pela qual você não gostaria de fazer isso é o Java-beans. A suposição de isSomethingé uma parte dessa especificação e muitas suposições são feitas em torno dela, para o bem ou para o mal, indo contra isso com doesSomethinga vontade de quebrar as coisas de maneiras não tão óbvias, levando a erros.

0

A questão é perfeitamente razoável. Às vezes, renomear o método gerado automaticamente não é suficiente. Exemplo: Espera-se isXyz()que os beans gerenciados JSF tenham como método getter de uma boolean xyzpropriedade.

Concordo com o BlackPanther, que sugere renomear o campo parente usá-lo isParentcomo o nome do método. De acordo com o princípio de ocultação de informações, a legibilidade dos métodos getter e setter é mais importante que a do atributo.

— Paulo Merson
fonte