BACK

Object Calisthenics, por que você não pratica?

Kleber MoraesMar. 13 - 7 min read

Por que eu sei que você não usa?

O tempo passa e os desenvolvedores ainda continuam fazendo errado, Jeff Bay no final de 2007 início de 2008, escreveu no ThoughtWorks Anthology, sobre Object Calisthenics.

São basicamente 9 passo, apenas 9 ações que você desenvolvedor deveria estar fazendo, mas não está. Sabe como eu sei que não está, porque faz mais de 10 anos desde a publicação, e ainda muitos devs não sabem o que é.

Logo, a quantidade de outros desenvolvedores aumenta sem saber o conceito.

Praticar Object Calisthenics, não é só fazer o certo, é melhorar como programador/desenvolvedor.

Mas o que é de fato?

São estas as nove regras:

Use apenas um nível de indentação por método.
Não use a ELSE.
Encapsule todos os tipos primitivos.
Encapsule suas collections em classes.
Não abrevie.
Mantenha todas as entidades pequenas.
Não use classes com mais de duas variáveis de instância.
Use apenas um método por linha.
Não use getters / setters / properties.

Sério, é isso mesmo?

Pense que é uma escada, cada parte tem que estar firme para alcançar o próximo passo, existem muitos artigos espalhados, cada artigo vai dar os toques especiais para cada linguagem, mas de modo geral, vou colocar o mesmo exemplo que está na publicação.

Regra 1 - Um nível de indentação por método

Já olhou para um grande método antigo perguntando por onde começar? Um método gigante não tem coesão.

Uma diretriz é limitar o comprimento do método a 5 linhas, mas esse tipo de transição pode ser assustador se o seu código estiver cheio de monstros de 500 linhas.

Em vez disso, tente garantir que cada método faça exatamente uma coisa - uma estrutura de controle ou um bloco de instruções, por método.

Se você tem estruturas de controle aninhadas em um método, está trabalhando em vários níveis de abstração, e isso significa que você está fazendo mais de uma coisa.

À medida que você trabalha com métodos que fazem exatamente uma coisa, expressa nas classes fazendo exatamente uma coisa, seu código começa a mudar. À medida que cada unidade em sua aplicação se torna menor, seu nível de reutilização começará a aumentar exponencialmente.

Pode ser difícil identificar oportunidades de reutilização dentro de um método que tenha cinco responsabilidades e seja implementado em 100 linhas.

Um método de três linhas que gerencia o estado de um único objeto em um determinado contexto é utilizável em muitos contextos diferentes.

Antes

class Board 
{
  ...

  String board() 
  {
    StringBuffer buf = new StringBuffer();
    for (int i = 0; i < 10; i++) 
    {
      for (int j = 0; j < 10; j++) 
      {
        buf.append(data[i][j]);
      }
      buf.append("\n");
    } 
    return buf.toString();
  }
}

Depois

class Board 
{
  ...

  String board() 
  {
    StringBuffer buf = new StringBuffer();
    collectRows(buf);
    return buf.toString();
  }

  void collectRows(StringBuffer buf) 
  {
    for (int i = 0; i < 10; i++) 
    {
      collectRow(buf, i);
    }
  }

  void collectRow(StringBuffer buf, int row) 
  {
    for (int i = 0; i < 10; i++) 
    {
      buf.append(data[row][i]);
    }
    buf.append("\n");
  }
}

Observe que outro efeito ocorreu com essa refatoração. Cada método individual tornou-se praticamente trivial para combinar sua implementação com seu nome. Determinar a existência de bugs nesses snippets muito menores é freqüentemente muito mais fácil.

Regra 2: não use ELSE

Todo programador entende a construção if / else. Ele é incorporado a quase todas as linguagens de programação e a lógica condicional simples é fácil para qualquer um entender. Quase todos os programadores viram uma condicional aninhada desagradável impossível de seguir ou uma declaração de caso que se prolonga por páginas. Pior ainda, é muito fácil simplesmente adicionar outra ramificação a uma condição existente, em vez de incluir uma solução melhor. Condicionais também são uma fonte freqüente de duplicação. Sinalizadores de status e estado de residência são dois exemplos que frequentemente levam a esse tipo de problema:

if (status == DONE) 
{ 
    doSomething(); 
} 
else 
{
    ...
}

Linguagens orientadas a objetos nos dão uma ferramenta poderosa, polimorfismo, para lidar com casos condicionais complexos. Designs que usam polimorfismo podem ser mais fáceis de ler e manter, e expressar sua intenção mais claramente. Mas nem sempre é fácil fazer a transição, especialmente quando temos o ELSE no bolso de trás. Então, como parte deste exercício, você não tem permissão para usar o ELSE. Tente o padrão de objeto nulo; pode ajudar em algumas situações. Existem outras ferramentas que podem ajudá-lo a se livrar do outro também. Veja quantas alternativas você pode criar.

Regra 3 -Encapsule todos os tipos primitivos.

Em liguagem fortemente tipadas, int é um objeto primitivo, não um objeto real, portanto obedece a regras diferentes dos objetos. É usado com uma sintaxe que não é orientada a objetos. Mais importante, um int por si só é apenas um escalar, por isso não tem significado. Quando um método usa um int como parâmetro, o nome do método precisa fazer todo o trabalho de expressar a intenção. Se o mesmo método usar Hora como parâmetro, é muito mais fácil ver o que está acontecendo. Objetos pequenos como esse podem tornar os programas mais fáceis de manter, pois não é possível passar Ano para um método que use um parâmetro Hora. Com uma variável primitiva, o compilador não pode ajudá-lo a escrever programas semanticamente corretos. Com um objeto, mesmo um pequeno, você está dando ao compilador e ao programador informações adicionais sobre o valor e por que ele está sendo usado.

Objetos pequenos, como Hora ou Dinheiro, também nos dão um lugar óbvio para colocar um comportamento que, de outra forma, estaria cheio de outras classes. Isso se torna especialmente verdadeiro quando você aplica a Regra 9 e somente o objeto pequeno pode acessar o valor. Observe que isso não significa usar wrappers de objetos que estão disponíveis na linguagem. Usar um Integer em vez de um int não confere vantagens adicionais em termos de expressar a intenção, ao passo que usar um wrapper que expresse significado dentro do domínio do problema tanto esclarece seu uso como torna evidente a intenção.