{"id":158,"date":"2011-07-29T21:26:52","date_gmt":"2011-07-29T21:26:52","guid":{"rendered":"http:\/\/leonardocotta.com.br\/blog\/?p=158"},"modified":"2011-07-29T21:26:52","modified_gmt":"2011-07-29T21:26:52","slug":"em-busca-do-nome-adequado-metodos-variaveis-e-classes","status":"publish","type":"post","link":"https:\/\/leonardocotta.com.br\/?p=158","title":{"rendered":"Em busca do nome adequado: m\u00e9todos, vari\u00e1veis e classes"},"content":{"rendered":"

\u00c9 muito comum ap\u00f3s alguns dias de trabalho em um projeto perceber que as escolhas de nomes de classes e m\u00e9todos n\u00e3o condizem com o que cada um representa. Isso acontece pois, com o passar do tempo, aumenta o nosso conhecimento sobre o dom\u00ednio do problema. Tamb\u00e9m \u00e9 natural surgir o desejo de mudan\u00e7a: a medida que nos especializamos nesse dom\u00ednio, o modelo do neg\u00f3cio em nossa mente passa a ser diferente da vis\u00e3o inicial. Um exemplo simples dessa mudan\u00e7a acontece quando em OO criamos um relacionamento bidirecional entre duas classes atrav\u00e9s de listas, como no exemplo a seguir:<\/p>\n

<\/p>\n

\n
\n\n\n\n
\n
\n
\/\/ a representa\u00e7\u00e3o de um cliente, funcion\u00e1rio etc<\/code><\/div>\n
public<\/code> class<\/code> Pessoa {<\/code><\/div>\n
<\/code>List<Conta> contas;<\/code><\/div>\n
}<\/code><\/div>\n
\/\/ a representa\u00e7\u00e3o de uma conta banc\u00e1ria (poupan\u00e7a, corrente, investimento etc)<\/code><\/div>\n
public<\/code> class<\/code> Conta {<\/code><\/div>\n
<\/code>List<Pessoa> pessoas;<\/code><\/div>\n
}<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

A primeira vista esse \u00e9 o relacionamento entre as duas entidades mas em determinado momento notamos que na verdade a rela\u00e7\u00e3o entre pessoa e conta \u00e9 um Titular, que possue caracter\u00edsticas pr\u00f3prias, como o contrato que ele como titular da conta assinou:<\/p>\n

\n
\n\n\n\n
\n
\n
public<\/code> class<\/code> Pessoa {<\/code><\/div>\n
<\/code>List<Titular> titularidades;<\/code><\/div>\n
}<\/code><\/div>\n
public<\/code> class<\/code> Conta {<\/code><\/div>\n
<\/code>List<Titular> titulares;<\/code><\/div>\n
}<\/code><\/div>\n
public<\/code> class<\/code> Titular {<\/code><\/div>\n
<\/code>Conta conta;<\/code><\/div>\n
<\/code>Pessoa pessoa;<\/code><\/div>\n
<\/code>\/\/ outras caracter\u00edsticas de uma titularidade<\/code><\/div>\n
}<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Nesse caso o processo de refatora\u00e7\u00e3o envolve extrair uma classe que representa tal rela\u00e7\u00e3o, um Titular: um exemplo simples que demonstra como em OO \u00e9 comum a exist\u00eancia de classes para representar informa\u00e7\u00f5es intang\u00edveis.<\/p>\n

Outras quest\u00f5es simples mas fundamentais para\u00a0o bom design e legibilidade da aplica\u00e7\u00e3o est\u00e3o ligados aos nomes que escolhemos<\/a>, n\u00e3o s\u00f3 em rela\u00e7\u00e3o ao nome da classe e de seus m\u00e9todos. No exemplo acima, por uma escolha fraca no nome da vari\u00e1vel membro\u00a0conta<\/strong> e\u00a0pessoa<\/strong> acabamos com um c\u00f3digo que parece repetitivo e pouco descritivo:<\/p>\n

\n
\n\n\n\n
\n
\n
Pessoa pessoa;<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Se em nosso sistema funcion\u00e1rios, gerentes, titulares e caixas s\u00e3o representados atrav\u00e9s de inst\u00e2ncias do tipo\u00a0Pessoa<\/code>, o mais adequado seria nome\u00e1-los de acordo:<\/p>\n

\n
\n\n\n\n
\n
\n
public<\/code> class<\/code> Titular {<\/code><\/div>\n
<\/code>Conta conta;<\/code><\/div>\n
<\/code>Pessoa cliente;<\/code><\/div>\n
}<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

A tend\u00eancia natural do desenvolvedor em linguagens que obrigam a declara\u00e7\u00e3o do tipo \u00e9 criar vari\u00e1veis com nome identicos ao tipo declarado, por ser um atalho das IDEs e mais simples de escrever. Mas tais alternativas, como visto, dizem pouco sobre a vari\u00e1vel que est\u00e1 sendo acessada. Por esses motivos, \u00e9 muito comum encontrar c\u00f3digo como:<\/p>\n

\n
\n\n\n\n
\n
\n
Cliente cliente = clienteDao.busca(<\/code>13<\/code>);<\/code><\/div>\n
Pagamento pagamento = pagamentoDao.busca(<\/code>15<\/code>);<\/code><\/div>\n
ProcessadorDePagamento processador =<\/code><\/div>\n
<\/code>new<\/code> ProcessadorDePagamento();<\/code><\/div>\n
processador.processa(cliente, pagamento);<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Cliente, pagamento, processador: \u00e9 somente desses tr\u00eas elementos que nosso dom\u00ednio \u00e9 composto? E nem mesmo Ruby foge disso, sendo comum encontrar:<\/p>\n

\n
\n\n\n\n
\n
\n
cliente = Cliente.find_by_id <\/code>13<\/code><\/div>\n
pagamento = Pagamento.find_by_id <\/code>15<\/code><\/div>\n
processador = Processador.<\/code>new<\/code><\/div>\n
processador.processa cliente, pagamento<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Tr\u00eas apari\u00e7\u00f5es de cliente, tr\u00eas de pagamento, quatro de processador. Aqui existe uma vis\u00e3o distorcida de que vari\u00e1veis s\u00e3o somente aquilo que o tipo descreve: um cliente, um pagamento, um processador. Na verdade elas referenciam inst\u00e2ncias espec\u00edficas e especializadas de um tipo determinado. S\u00f3 faria sentido chamar o cliente 13 de\u00a0cliente<\/strong> se ele \u00e9 o \u00fanico cliente, um singleton. Especialize o nome de suas vari\u00e1veis e crie um c\u00f3digo mais leg\u00edvel:<\/p>\n

\n
\n\n\n\n
\n
\n
Cliente devedor = clientes.busca(<\/code>13<\/code>);<\/code><\/div>\n
Pagamento fatura = pagamentos.busca(<\/code>15<\/code>);<\/code><\/div>\n
ProcessadorDePagamento mensalidade =<\/code><\/div>\n
<\/code>new<\/code> ProcessadorDePagamento();<\/code><\/div>\n
mensalidade.cobra(devedor, fatura);<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

O mesmo pode ser refletido no exemplo de Ruby. E como trabalharemos nossos reposit\u00f3rios para permitir uma maior legibilidade do c\u00f3digo?<\/p>\n

\n
\n\n\n\n
\n
\n
Pessoa pessoa = ...;<\/code><\/div>\n
List<Conta> contas = dao.contasDe(pessoa);<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Note como por causa da escolha do nome da vari\u00e1vel\u00a0pessoa<\/code> fomos obrigados a colocar algo mais descritivo no m\u00e9todo. Caso a vari\u00e1vel possua um nome mais adequado, ter\u00edamos ent\u00e3o:<\/p>\n

\n
\n\n\n\n
\n
\n
Pessoa cliente = ...;<\/code><\/div>\n
List<Conta> contas = dao.contasDe(cliente);<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Modificando nossa classe\u00a0Conta<\/code> para adicionar o gerente e o subgerente temos novamente o sentido das vari\u00e1veis descrito n\u00e3o s\u00f3 pelo seu tipo, mas tamb\u00e9m pelo seu nome:<\/p>\n

\n
\n\n\n\n
\n
\n
public<\/code> class<\/code> Conta {<\/code><\/div>\n
<\/code>List<Titular> titulares;<\/code><\/div>\n
<\/code>Pessoa gerente;<\/code><\/div>\n
<\/code>Pessoa subgerente;<\/code><\/div>\n
}<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Nesse instante a query ficaria mais complexa pois existem dois relacionamentos distintos com pessoa, requerendo\u00a0a cria\u00e7\u00e3o de uma DSL interna para query. No exemplo a seguir usamos um builder para facilitar a constru\u00e7\u00e3o da query:<\/p>\n

\n
\n\n\n\n
\n
\n
Pessoa gerente = ...;<\/code><\/div>\n
Pessoa subgerente = ...;<\/code><\/div>\n
List<Conta> contas =<\/code><\/div>\n
<\/code>dao.comGerenteESubgerente<\/code><\/div>\n
<\/code>(gerente, subgerente):<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Essa \u00e9 a abordagem que o jbehave 3.2 e o selenium utilizam, onde acabamos por ter uma sintaxe muito longa e repetitiva.<\/p>\n

Retomando o problema do nome das vari\u00e1veis, que pode ser resolvido com outra refatora\u00e7\u00e3o de rename: o c\u00f3digo da terceira linha \u00e9 mais descritivo que o anterior:<\/p>\n

\n
\n\n\n\n
\n
\n
Pessoa gerente = ...;<\/code><\/div>\n
Pessoa subgerente = ...;<\/code><\/div>\n
List<Conta> contas =<\/code><\/div>\n
<\/code>dao.comGerente(gerente)<\/code><\/div>\n
<\/code>.comSubgerente(subgerente):<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Em linguagens onde mapas podem ser representados atrav\u00e9s de literais, o ru\u00eddo sint\u00e1tico \u00e9 baixo e permite que seja escrito c\u00f3digo como a seguir em Ruby:<\/p>\n

\n
\n\n\n\n
\n
\n
gerente = ...<\/code><\/div>\n
subgerente = ...<\/code><\/div>\n
contas = Conta.com<\/code><\/div>\n
<\/code>:gerente<\/code> => gerente, <\/code>:subgerente<\/code> => subgerente<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

Novamente, a refatora\u00e7\u00e3o aqui \u00e9 fundamental:<\/p>\n

\n
\n\n\n\n
\n
\n
principal = ...<\/code><\/div>\n
secundario = ...<\/code><\/div>\n
contas = Conta.com<\/code><\/div>\n
<\/code>:gerente<\/code> => principal, <\/code>:subgerente<\/code> => secundario<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n

A escolha dos nomes de nossas classes influencia o design e legibilidade de nosso c\u00f3digo direta e indiretamente, primeiro pela declara\u00e7\u00e3o das vari\u00e1veis e a nossa vis\u00e3o do dom\u00ednio. Depois pelas consequ\u00eancias que o mesmo possui na escolha dos nomes das vari\u00e1veis e m\u00e9todos, que permitem um design mais ou menos leg\u00edvel.<\/p>\n

Essa escolha \u00e9 t\u00e3o importante quanto o resto de seu design para facilitar a compreens\u00e3o do que seu dom\u00ednio \u00e9 e qual o problema que est\u00e1 tentando atacar. Na pr\u00f3xima vez que for declarar uma vari\u00e1vel com o mesmo nome que o tipo, pense duas vezes.<\/p>\n

Retirado de :\u00a0http:\/\/blog.caelum.com.br\/em-busca-do-nome-adequado-metodos-variaveis-e-classes\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

\u00c9 muito comum ap\u00f3s alguns dias de trabalho em um projeto perceber que as escolhas de nomes de classes e m\u00e9todos n\u00e3o condizem com o que cada um representa. Isso acontece pois, com o passar do tempo, aumenta o nosso conhecimento sobre o dom\u00ednio do problema. Tamb\u00e9m \u00e9 natural surgir o desejo de mudan\u00e7a: a … Continue reading Em busca do nome adequado: m\u00e9todos, vari\u00e1veis e classes<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[26],"tags":[86,101,104,109,113,151,225,234],"class_list":["post-158","post","type-post","status-publish","format-standard","hentry","category-sem-categoria","tag-clean-code","tag-ddd","tag-design","tag-domain-driven-design","tag-engenharia","tag-java","tag-rails","tag-ruby"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t