BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Qual é a nomenclatura ideal para os nosso métodos?

Qual é a nomenclatura ideal para os nosso métodos?

Uma boa prática é sempre analisar projetos open source e comparar com a forma que trabalhamos, com tais comparações conseguimos absorver conhecimento e experiência que pode ser útil nos nosso projetos, recentemente Anderson Fraga, no fórum Tectura, iniciou uma discussão onde ele faz um questionamento familiar para muitos desenvolvedores, ele comparou a declaração de métodos e classes do projeto Restfulie e viu que no projeto foi usado nomes curtos e expressivos.

Diante disso iniciou-se um questionamento sobre que nomenclatura usar, vejam a pergunta feita pelo Anderson:
Diante disso, tenho uma curiosidade: o que vocês estabelecem como padrão para usarem nos models? Nomes curtos (e.g. class User, método buscar) ou nomes mais complexos e descritivos, semelhantes aos recomendados para TDD (e.g. class User, método buscarPeloId). Qual idéia/metodologia vocês usam?
A discussão está bem animada e inicialmente pendeu para o lado dos testes, Geraldo Ferraz destacou um ponto importante:
As vezes a expressividade prejudica a legibilidade, como no caso:
 
@Test
verificaSePodeHabilitarNovoRegistroPassandoParametroInvalido(){}
 
acho q tudo deve ser um balanceamento entre expressividade e legibilidade
Guilherme Silveira, destacou: "Em geral, prefiro nomes longos e que digam exatamente o que deveriam fazer", o exemplo dado por ele foi:
it "deveria enviar um email caso ocorra um erro" do
end
O exemplo dado por Guilherme é um caso de testes de unidade escrito em Ruby utilizando o framework de testes RSpec. Para os programadores Ruby, criar testes com nomes expressivos é uma tarefa relativamente fácil dado que os frameworks de testes facilitam ajudam muito. Mas e com Java? Carlos Alberto comentou dizendo que utilizando JUnit também é possível criar testes bem expressivos, o exemplo dado foi:
public class GerenciamentoClientesManagedBeanTest {
 
@Test public void filtrandoClientes(){
dadoQueEstouAcessandoComoGerenteDaLoja();
eEstouGerenciandoMeusClientes();
ePossuoClientesCadastrados();
quandoInformarCriteriosDeBusca();
eSolicitarPesquisaPorClientes();
oSistemaDeveriaApresentarAListaDeClientes();
masSeEuNaoTiverClientesParaOsCriteriosInformados();
eSolicitarPesquisaPorClientes();
oSistemaDeveriaExibirMensagem("Não a Clientes para os critérios informados");
masSeAlgumCampoDoCriterioDeBuscaFoiInformadoIncorretamente();
eSolicitarPesquisaPorClientes();
oSistemaDeveriaEmitirMensagem("Informe Critérios de busca corretamente");
masSeEuEstiverComAlgumErroNoSistemaDeBuscasPorClientes();
eSolicitarPesquisaPorClientes();
oSistemaDeveriaExibirMensagem("Erro no sistema, não foi possível efetuar busca");
oSistemaDeveriaLogarOErroNoLog();
}
}
Uma outra estratégia utilizada por Cecília Fernandes no projeto Calopsita, também chamou muito a atenção, usando a estrutura do JUnit e Fluent Interfaces, ela utilizou um esquema de modelo de programação compondo métodos que chamou bastante a atenção de todos, vejam a implementação dela:
@Test
public void addACardInAnIteration() {
given.thereIsAnUserNamed("sergio").and()
.thereIsAProjectNamed("IEs4Linux")
.ownedBy("sergio")
.withACardNamed("support IE8")
.planningCard()
.whichDescriptionIs("IE8 must be supported").and()
.withAnIterationWhichGoalIs("new release").and()
.iAmLoggedInAs("sergio");
when.iOpenProjectPageOf("IEs4Linux").and()
.iOpenThePageOfIterationWithGoal("new release").and()
.iAddTheCard("support IE8").inThisIteration();
then.theCard("support IE8")
.appearsOnList("iteration_cards");
}
Complementando a discussão Guilherme Silveira, deu uma sugestão muito boa, citando o que Lucas Cavalcanti disse:
Como a sugestão que o Lucas deu, componha um comportamento longo por diversos comportamentos menores.
Existem diversos padrões para fazer isso como neste post do blog da Caelum.
A tendência que temos observado foi a sugestão de usos de nomes curtos usando composição para descrever comportamentos mais complexos, um dos gurus do desenvolvimento de software, Martin Flower fala exatamente sobre isso e, em um de seus artigos sobre fluent interfaces, cita que o uso de tal conceito, contribui para a criação de uma API que pode compor comportamentos complexo com base em comportamentos mais simples. Reparem no projeto Calopsita citado neste artigo, ele usa uma abordagem semelhante, ficando fácil entender o que o software está fazendo apenas lendo os métodos invocados. Com o uso dos operadores lógicos, vimos como pode ser composto o comportamento aumentando as funcionalidades do software sem aumentar a complexidade, basta reparar que uma composição assim significa mais do que métodos encadeados, significa uma transmissão de conhecimento de negócio através do código.
 
O ser humano normalmente divide uma coisa complexa para torná-la mais fácil de ser entendida, ao desenvolver pense nos exemplos apresentados acima, e procure tentar incorporar isso ao seu desenvolvimento assim você tem apenas a ganhar.

 

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT