Reduzindo o Tamanho de Listas de Parâmetros de um Método

a) Smell a ser reduzido/eliminado: Long Parameter List

b) Ingredientes

Ferramentas

Métrica(s) associada(s): número de parâmetros por método (Number of Parameters in Method – PAR)

Técnicas

Mecânica

  1. Identificar pontos onde o smell ocorre (PMD com Maven)
  2. Garantir que todas as ocorrências de código duplicado tenham um nível satisfatório de cobertura de testes (uso do JaCoCo)
  3. Caso a cobertura não esteja satisfatória, escrever testes unitários que garantam o comportamento (introduzir mais testes com JUnit, acompanhando sua cobertura com JaCoCo)
  4. Aplicar as técnicas de refactoring
  5. Rodar métricas novamente para verificar a melhoria
  6. Repita o passo 1

c) Aplicando a Receita no Projeto ArgoUML

Base de código: ArgoUML (http://argouml.tigris.org/)

Repositório utilizado: https://github.com/carlosaml/argouml

Configuração de ferramentas

  • Maven utilizado para o build
  • PMD configurado para detectar métodos com mais de 6 parâmetros
  • Testes JUnit rodando atráves do Maven
  • JaCoCo plugado no Maven para geração de relatórios de cobertura de testes

Aplicação da Receita

Executando o build do Maven, o relatório do PMD acusa que o seguinte método recebe muitos parâmetros:

private String toString(Object modelElement, boolean useGuillemets, 

            boolean showVisibility, boolean showMultiplicity, boolean showTypes,

            boolean showInitialValues, boolean showProperties)

Portanto, utilizaremos ele como base para a aplicação desta receita.

Primeiramente verificamos a cobertura de testes dos chamadores deste método (pelo fato do mesmo ser privado), que é apenas um:

public String toString(Object modelElement, NotationSettings settings)

O relatório de cobertura de testes existente não passa a confiança necessária para que o método possa ser refatorado. Para melhorar este cenário, escreve-se mais testes para o método público.

Para isso, a classe TestAttributeNotationUml, contendo cinco testes unitários, é adicionada.

Com isso eleva-se a cobertura de testes e consequentemente consegue-se autorização para refatorar o método toString que conta com muitos parâmetros.

Procurando pelos usos do método em questão, vemos que existe apenas um e que este apenas extrai os valores de algumas propriedades do objeto NotationSettings recebido e os passa adiante. Isso define claramente um ótimo candidato para Preserve Whole Object, já que muitos dos parâmetros do método são fortemente relacionados.

Para isso, substituímos todos estes parâmetros:

  • boolean useGuillemets
  • boolean showVisibility
  • boolean showMultiplicity
  • boolean showTypes
  • boolean showInitialValues
  • boolean showProperties

Por apenas um:

  • NotationSettings settings

E mudamos a única chamada do método para que passe diretamente a instância de NotationSettings.

Com isso o PMD já não acusa mais o método em seu relatório.

Porém, o método recém refatorado conta com somente um uso, o que não faz sentido devido ao fato do mesmo ser privado. Para tanto, podemos aplicar Inline Method e eliminar o método privado em questão.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s