Refatorando com confiança!

Você já encontrou algum código e pensou: “Nossa, que código bom!”? (obs: ler com voz irônica).

Talvez sim, mas provavelmente a proporção de base de códigos bom vs ruins é bem baixa. O que leva alguém a escrever um código ruim? Com certeza a habilidade e experiência da pessoa influencia na qualidade do seu código, meus primeiros códigos não tinham a mesma qualidade dos que escrevo hoje (ainda bem!).

Eu acredito que o principal fator que torna um código ruim não é a pessoa que escreveu, mas sim as várias pessoas que passaram por aquele código e não o melhoraram quando necessário (e já adianto que nem vou falar sobre a falta de tempo).

Qual o melhor momento para refatorar código?

Quando você precisa mudar um código para implementar uma nova funcionalidade. Não, não é durante o code review e nem fora das horas de trabalho.

Refatorar fora das horas de trabalho (horas que o time concorda em estar junto trabalhando) cria a cultura do heroísmo onde uma pessoa salva o projeto. O problema é que precisa de um herói para terminar o trabalho de outro herói, e ai já viu né.

Durante o code review é comum fazermos pequenas sugestões, alertar sobre código duplicado ou até conflitos de funcionalidade.

Durante a revisão de código quem está revisando provavelmente não sabe como aquele código vai precisar evoluir, então qualquer sugestão é baseada apenas na experiência da pessoa, é só um chute. Se aquela parte do código nunca mais for tocada, não importa se o código tá duplicado ou se a modelagem está bem feita, se os testes passam e o código funciona tá tudo bem.

Na hora de mudar vai tá tudo uma bagunça

Sim, provavelmente, e isso é bom! Na hora que precisar mudar você vai ter mais contexto de como o código precisa evoluir e qual seria um bom design, o que é bem melhor do que só um chute.

(Essa ideia de que revisão de código aumenta a qualidade do código é o que mais me incomoda na cultura de Pull Requests, mas essa polêmica fica pra outro post)

O que realmente causa a bagunça não é quem escreveu o código (a coitada da pessoa que escreveu não tinha como prever o futuro, certo?) é quem passa por ele e não se preocupa em melhorar.

Uma ideia interessante do livro 99 Bottles of OOP (um excelente livro da Sandi Metz e Katrina Owen, super recomendo) é o Shameless Green, que basicamente segue a ideia do TDD a risca. Escreva o código que faz os testes passarem e pronto.

Não adianta especular generalizações e nem forçar todas as abstrações de domínio possíveis. Apenas se preocupe em escrever o código que faz os testes passarem e confie que quando uma mudança for necessária, a pessoa que estiver escrevendo o código vai melhorá-lo.

Regras de negócio mudam, pessoas ganham mais conhecimento do negócio, da aplicação e de escrita de código em geral, é normal que o código precise de pequenas (ou grandes) melhorias de vez em quando.

Refatore com confiança!

Considerando que você tem mais contexto de quem escreveu o código original é hora de procurar por pontos de melhoria, e ai entram os code smells!

Eu já devo ter escrito por aqui outras vezes mas é sempre bom relembrar: identifique code smells primeiro refatore depois.

Um ponto importante sobre code smells é que eles não são estáticos (apesar de existirem ferramentas de análise estática de código que funcionam muito bem). Pense por um instante: qual é o real problema com o código duplicado?

Eu não acho que é ter duas (ou mais) partes parecidas de código fazendo a mesma coisa, mas sim alguma abstração do domínio que precisa ser identificada.

Aliar o contexto de negócio, sabendo como o código precisa evoluir, com o conhecimento de escrita de software é crucial.

Se você quiser conhecer mais sobre refatoração, padrões de projeto e design orientado a objetos colocando a mão na massa, dá uma olhada nos livros Refatorando com Padrões de Projeto (com versão em Ruby e Java).

Anúncios

Novo livro: Refatorando com Padrões de Projeto, um guia em Java!

Se você gosta de padrões de projeto e curte as publicações do blog, o livro Refatorando com Padrões de Projeto, um guia em Java é perfeito para você!

livro java

Sobre o livro

Se você já leu a série Mão na Massa sobre Padrões de Projeto aqui do blog, você vai curtir ler o livro. Segui a mesma ideia de ter exemplos práticos para utilização dos padrões, mas adicionei um pensamento mais crítico para a implementação através de técnicas de refatoração.

O conteúdo é o mesmo da edição em Ruby, mas adaptado ao contexto da linguagem Java, explorando as diferenças de linguagens estaticamente tipadas mas compartilhando as mesmas ideias: aplicar pequenas mudanças com visando alcançar um design melhor com Padrões de Projeto.

Público Alvo

Ter um entendimento bom de Orientação a Objetos é importante, mas muitas vezes é difícil encontrar exemplos práticos tanto de problemas quanto de boas soluções para o seu design.

Se você se encontra nesse meio termo, alguém que já passou pelo básico e está procurando um material mais prático, o livro vai te ajudar a entender o papel dos Padrões de Projeto no design e como Refatoração auxilia na hora de por a mão na massa!

Developer Experience

Já parou para pensar nas ferramentas que você, desenvolvedor, usa no dia-a-dia? Do editor de texto/IDE até como o software é implantado em produção, o que você utiliza precisam oferecer uma boa experiência, assim como um novo modelo de celular.

A evolução da Experiência de Uso (User eXperience – UX) nos proporciona maneiras cada vez melhores de interagir com nossos dispositivos, software e até nós mesmos. De maneira semelhante a evolução da Experiência de Desenvolvimento muda a maneira como o software é desenvolvido e como interagimos em equipe.

A revolução da Nuvem

Um grande benefício, poucas vezes reconhecido, de utilizar um serviço como Amazon ou Heroku é poder criá-las sem muita burocracia. Um git push e sua aplicação está rodando no Heroku, sem dependências com um time de infraestrutura.

De maneira semelhante, a popularização de contêineres com o Docker permite que você consiga rodar na sua máquina uns dois servidores Phoenix com um NGINX para balancear a carga, um Mongo para guardar dados, Memcached para fazer caching e um Nagios para monitorar tudo isso. Tá, talvez não tudo isso, mas dá pra endenter a ideia 🙂

O benefício de poder experimentar com tecnologias diferentes e colocá-las em produção sem muitas adaptações na infraestrutura aumenta muito a experiência de desenvolvimento.

O tempo para Hello World

O Hello World é a maneira mais fácil de experimentar uma ferramenta nova, não é nada complexo complexa e dá uma boa visão sobre como configurar um ambiente. O framework Rails ficou bem conhecido pela sua capacidade de permitir experimentação muito rápido, basta rodar alguns simples comandos e você tem uma estrutura completa, com views e banco de dados 100% funcionais.

Hoje em dia praticamente qualquer framework oferece alguma maneira de criar uma estrutura básica, com diretórios e configurações básicas. A linguagem Crystal (https://crystal-lang.org) já possui um comando que inicializa os diretórios, cria arquivos básicos, testes e inclusive configurações de um repositório Git – isso não é uma biblioteca, o executável da linguagem oferece isso!

Outro bom exemplo é o http://tryruby.org/ que permite aprender sobre a linguagem Ruby direto no navegador, sem instalar nada. Essa ideia levou o primeiro contato com a linguagem para outro nível de facilidade e hoje em dia várias linguagens/ferramentas possuem algo do tipo, como o tutorial de Go https://tour.golang.org/.

Esses são só alguns exemplos de como a preocupação em melhorar a vida dos desenvolvedores leva a criação de novas ferramentas que simplificam e facilitam seu uso. Nos próximos posts vamos explorar melhor o impacto dessas facilidades nos times de software, então acompanhe o blog e fique ligado 🙂

3 dicas para utilizar Padrões de Projeto

Aplicar um Padrão de Projeto pode ser um processo não muito simples, então siga essas dicas para ter mais confiança e entendimento antes de começar. Se quiser ir mais afundo no tema e entender como Padrões de Projeto podem ajudar, leia o livro Refatorando com Padrões de Projeto.

  1. Identifique a oportunidade de melhoria: Aplicar um Padrão de Projeto aumenta a complexidade do código, portanto é preciso ter certeza que vale a pena aplicá-lo. Comece pensando no que o código ganharia se o padrão for aplicado, pode ser tanto um code smell que será resolvido quanto uma alteração futura que será facilitada.
  2. Entenda o contexto do código: Cada Padrão de Projeto possui um contexto onde ele faz sentido e de fato resolve o problema, apesar de aumentar a complexidade. Aplicar um padrão fora de contexto vai causar tanto dificultar sua implementação quanto dificultar o entendimento dos outros. O coitado do Builder que o diga.
  3. Aplique pequenas mudanças nos testes e no código: No post anterior falei sobre a diferença entre refatorar e mudar o código, se quiser aplicar um padrão refatore! Essas mudanças em pequenos passos, além de te dar mais segurança, também servem para te dar um entendimento melhor do design que você está propondo. Pode ser que no meio da refatoração você descubra que apenas modificar um pouco o design resolve o problema, sem adicionar toda a complexidade dos padrões.

Lembre-se sempre que Padrões de Projeto adicionam complexidade ao código, então é preciso entender se vale a pena aplicá-los ou não. Se decidir por aplicá-los, siga sempre refatorando o código, evite fazer grandes mudanças no código de qualquer jeito, seja um profissional disciplinado!

Aprendendo TDD! Utilizando Dublês de Teste

No posto anterior fizemos o famoso FizzBuzz utilizando os testes como guia e analisando as decisões de design tomadas ao longo do desenvolvimento. No entanto, no mundo real nem tudo consegue ser testado diretamente e são nesses casos que precisamos utilizar os dublês de teste!

O que são dublês de testes?

Precisamos alertar que a conta do usuário vai expirar caso o pagamento do último mês não tenha sido efetuado. Como adicionaríamos testes para o seguinte código?

class Usuario
  attr_reader :ultimo_pagamento
  UM_MES = 60*60*24*30

  def realizar_pagemento()
    @ultimo_pagamento = Time.now
  end

  def deve_expirar_conta()
    @ultimo_pagamento <= Time.now - (UM_MES)
  end
end

Obviamente não conseguimos fazer o pagamento e esperar um mês para verificar se a conta foi expirada, então precisamos utilizar um dublê de teste para fingir a passagem do tempo.

Dublês de testes são mais conhecidos como mocks, mas existem outros tipos. No artigo The Little Mocker, Uncle Bob explica de maneira bem fácil de acompanhar quais são os vários tipos de dublês, incluindo o mock, e quando é o melhor momento para utilizar cada um deles. No próximo post vamos entrar em mais detalhes sobre os diferentes dublês.

Para o código anterior nós vamos utilizar um stub, que permite alterar o comportamento de um método para ignorar sua lógica e retornar um valor específico. O que é exatamente o que precisamos para testar o código anterior, ao invés de Time.now retornar o tempo atual, vamos retornar uma data que permita exercitar o código.

Testes com dublês

A sintaxe para criar stubs e outros dublês muda um pouco de biblioteca para biblioteca, no caso do MiniTest, definimos o método que desejamos substituir o comportamento, o valor que deve ser retornado e o bloco de código onde aquele stub será válido.

require 'minitest/autorun'
require 'minitest/spec'
require_relative '../lib/usuario.rb'

describe Usuario do
  UM_MES =(60*60*24*30)
  it "expira conta quando pagamento nao foi feito" do
    usuario = Usuario.new
Time.stub(:now, Time.now() - UM_MES) do
      usuario.realizar_pagemento()
    end

usuario.deve_expirar_conta.must_equal true
  end
end

Além do tempo existem outras situações onde não queremos utilizar a implementação real dos métodos como por exemplo, chamadas de serviços externos pela rede, leitura de arquivos locais ou até mesmo chamadas ao banco de dados.

A principal vantagem que eu vejo de utilizar dublês ao fazer TDD é que eu consigo isolar melhor os meus testes e não preciso me preocupar muito com a maneira como outros objetos funcionam. Assim posso focar apenas no design do código que estou desenvolvendo e passar pelo ciclo do TDD mais facilmente. No entanto é preciso tomar cuidado para não utilizá-los de maneira errada!

Quando não utilizar

No artigo Mockar ou não mockar, eis a questão,  Fabio Pereira explora bem os malefícios de utilizar muitos dublês de testes no seu código.

Uma das guerras sagradas no desenvolvimento de software é definir o que é um teste unitário, pois algumas pessoas restrigem ao ponto de utilizar dublês para quaisquer outros objetos, isolando a classe que está sendo testada, outros sugerem que até mesmo chamadas ao banco de dados podem ser feitas em testes unitário.

Independente da sua definição de teste unitário, ao utilizarmos um dublê estamos ignorando toda a lógica implementada naquele método/classe em favor de isolar o teste. Caso essa lógica mude o teste não vai saber e é aí onde mora o perigo.

Devido a maneira como ruby lida com objetos, é possível que o método nem sequer exista mas que ainda assim o teste funcione. O código a seguir utiliza um mock para criar um objeto e simular o seu comportamento, mas a asserção é feita sobre o mock.

it "mata um panda" do
  usuario = MiniTest::Mock.new
  usuario.expect :metodo_inexistente, true

  usuario.metodo_inexistente.must_equal true
end

Utilizar dublês é necessário e tem muitos benefícios, como vimos no exemplo de testes com o tempo. No entanto é preciso ficar atento pois podemos utilizar tantos dublês que no final das contas o teste não testa nada, como nesse exemplo anterior.

No próximo post vamos explorar mais sobre dublês de testes e situações onde podemos utilizá-los para nossos testes.

Compartilhe os posts da série Aprendendo TDD! com seus amigos e colegas que também estão buscando aprender mais sobre essa técnica. E acompanhe o blog pois toda semana tem post novo! Dúvidas, sugestões e comentário podem ser feitas aqui no blog ou no twitter em @marcosbrizeno.

[Refatorando Tudo!] Não use parâmetros como retorno

Sabe quando você precisa encontrar aquele bug demoníaco e não faz a menor ideia de onde ele está? Ai você começa a debugar o código e põe break point em tudo que é lugar pra tentar entender o que está acontecendo. A pior coisa que você pode encontrar são métodos com efeitos colaterais.

Dano Colateral

Imagine que vamos processar a criação de um pedido de compras. Para isso precisamos calcular o valor do frete e verificar se o usuário fazendo a compra faz parte do programa premium da empresa para marcar o produto como entrega expressa. O código atual parece algo assim:

class PedidoController
  def criar_pedido
    pedido = Pedido.criar_pedido_do_carrinho
    usuario = Usuario.buscar_por_id(params.id_usuario)
    valor_frete = calcular_frete(pedido, usuario)
  end
# ...
  def calcular_frete(pedido, usuario)
    frete = pedido.valor_total > VALOR_COM_FRETE_GRATIS ?
              0 : pedido.valor_total * 0.10
    pedido.entrega_expressa = usuario.premium? && frete == 0
    transportadoras.enviar_aviso_entrega_expressa(pedido) if pedido.entrega_expressa?
    pedido.remover_produtos_estoque
    frete
  end

Vamos entender o que está acontecendo no método calcular_frete:

Primeiro o valor do frete é definido baseado no preço do pedido.

Depois marcamos o produto como entrega expressa e enviamos essa informação para as transportadoras, dependendo do valor do frete calculado antes.

Por fim os produtos do pedido são removidos do estoque e o valor do frete é retornado.

Bom, só pela explicação já deu pra perceber que esse método faz coisa demais né? Mas o principal problema, que provavelmente vai nos pegar no futuro são as alterações no objeto produto que acontecem dentro de um método chamado calcular_frete.

Imagine que a lógica para marcar o pedido como entrega expressa está errada e você precisa corrigi-lá. Não é intuitivo achar que no método calcular_frete o pedido é marcado como entrega expressa. Esse é o principal problema de métodos com efeitos colaterais.

Identificando qual anti-padrão estamos lidando

A regra mais óbvia para se seguir é:

Não altere objetos que são passados como parâmetro

Mas, uma vez que estamos nessa situação, como sair dela? Para isso precisamos entender o motivo de o método está alterando os parâmetros. Aqui vão algumas possibilidades:

Violando o Princípio da Responsabilidade Única

Se você não conhece o Princípio da Responsabilidade Única (Single Responsibility Principle), veja esse outro post que tem mais detalhes.

Como falado anteriormente, apesar de ser um exemplo simples, só pela explicação já fica claro a quantidade de coisas que o método calcular_frete faz é grande demais para um método só.

No entanto eu acho difícil seguir esse princípio pois definir o que é uma responsabilidade é muito subjetivo. Processar pagamento é uma responsabilidade? Ou será que buscar os produtos de um pedido deveria ser uma responsabilidade separada?

Tentando dividir as responsabilidades, podemos ter o seguinte cenário:

class PedidoController
  def criar_pedido
    pedido = Pedido.criar_pedido_do_carrinho
    usuario = Usuario.buscar_por_id(params.id_usuario)
    valor_frete = calcular_frete(pedido, usuario)
    marcar_pedido_expresso(pedido, usuario, valor_frete)
    enviar_aviso_entrega_expressa(pedido)
    pedido.remover_produtos_estoque
  end

  def calcular_frete(pedido, usuario)
    pedido.valor_total > VALOR_COM_FRETE_GRATIS ?
              0 : pedido.valor_total * 0.10
  end

  def marcar_pedido_expresso(pedido, usuario, frete)
    pedido.entrega_expressa = usuario.premium? && frete == 0
  end

  def enviar_aviso_entrega_expresa(pedido)
    transportadoras.enviar_aviso_entrega_expressa(pedido) if pedido.entrega_expressa?
  end
end

As responsabilidades estão bem separadas agora, mas será que realmente melhoramos o design da aplicação? Olhe o tamanho do método criar_pedido agora, ainda continuamos alterando um parâmetro no método marcar_pedido_expresso e será que esses outros métodos realmente fazem parte do PedidoController?

Ter o princípio em mente é uma boa maneira de guiar a refatoração, mas na prática vale mais a pena combiná-lo com outros princípios para decidir como refatorar o código.

Objetos com Inveja

O code smell Feature Envy mostra uma situações onde, para implementar certa funcionalidade, um objeto precisa consulta muito mais outros objetos do que a si mesmo.

Uma maneira bem fácil de perceber essa situação é olhar o método sem focar em uma linha específica. Volte ao código anterior e tente olhar todo o corpo do método buscando padrões e repetições.

Fica bem claro ver a quantidade de chamadas ao objeto pedido, seja para ler informações dele, passá-lo como parâmetro ou até mesmo modificá-lo. Esse é um sinal de que o PedidoController está com inveja das funcionalidades de Pedido.

Podemos refatorar o código movendo essas responsabilidades de PedidoController para Pedido:

class PedidoController
  def criar_pedido
    pedido = Pedido.criar_pedido_do_carrinho
    usuario = Usuario.buscar_por_id(params.id_usuario)
    valor_frete = calcular_frete(pedido, usuario)
    pedido.marcar_como_entrega_expressa(usuario, valor_frete)
    enviar_aviso_entrega_expressa(pedido)
    pedido.remover_produtos_estoque
  end

  def enviar_aviso_entrega_expresa(pedido)
    transportadoras.enviar_aviso_entrega_expressa(pedido) if pedido.entrega_expressa?
  end
end

class Pedido
  def marcar_como_entrega_expressa(usuario, frete)
    self.entrega_expressa = usuario.premium? && frete == 0
  end
end

Agora não temos mais o efeito colateral de marcar o pedido como entrega expressa em um lugar onde não fazia sentido. Caso essa lógica precise mudar ela está concentrada em um método dentro da classe Pedido.

Violando o Diga, não Pergunte!

No post anterior vimos o princípio Diga, não Pergunte, que tenta evitar que o comportamento dos objetos fique separado das informações.

Se o código consulta as informações de um objeto para decidir o que fazer com ele, é sinal de que o princípio está sendo violado. Podemos mover então a responsabilidade de falar com as transportadoras para a classe pedido, já que ela possui a informação necessária:

class PedidoController
  def criar_pedido
    pedido = Pedido.criar_pedido_do_carrinho
    usuario = Usuario.buscar_por_id(params.id_usuario)
    valor_frete = calcular_frete(pedido, usuario)
    pedido.marcar_como_entrega_expressa(usuario, valor_frete)
    pedido.enviar_aviso_entrega_expressa(transportadoras)
    pedido.remover_produtos_estoque
  end
end

class Pedido
  def marcar_como_entrega_expressa(usuario, frete)
    self.entrega_expressa = usuario.premium? && frete == 0
  end

  def enviar_aviso_entrega_expresa(transportadoras)
    transportadoras.enviar_aviso_entrega_expressa(self) if entrega_expressa?
  end
end

Mesmo após todas essas refatorações ainda continuamos com o método criar_pedido tendo muitas responsabilidades e acionando bastante o objeto pedido, apesar de que agora ele não o modifica diretamente.

Como poderíamos melhorar o design desse código? Pense um pouco em como você melhoraria esse código e deixa as suas ideias nos comentários abaixo.

Compartilhe o texto com seus colegas para ajudá-los a melhorar o código deles também e continue acompanhando os posts da série [Refatorando tudo!] para melhorar ainda mais seu código!

Deixe seus comentário aqui no post ou fale direto comigo no twitter em @marcosbrizeno!

 

 

[Refatorando Tudo!] Diga, não pergunte!

Esse são objetos burros, não devem ter nenhuma lógica

Ah… quantas vezes eu já ouvi isso… Geralmente esse argumento é reforçado por termos como beans ou POJOs (ou o equivalente da linguagem que você utiliza).

Voltando um pouco nos conceitos de Orientação a Objetos, a ideia básica é esconder os dados e expor comportamento. Assim, os objetos conseguem se comunicar e manter seu estado interno, o que facilitaria a manutenção do código.

Então ter “objetos burros” não só vai totalmente contra os princípios da orientação a objetos como também empurra lógica para classes onde elas não fazem sentido.

Dados andam junto com a lógica que precisa deles

Para exemplificar essa situação vamos exibir os detalhes de um pedido, como valor total, forma de pagamento utilizada, endereço de entrega etc. A informação de um pedido vem de um serviço, que retorna um JSON com todos os dados.

Utilizando um biblioteca que para mapear JSON para um objeto, como Jackson por exemplo, criamos a seguinte classe:
(para reduzir a quantidade de código focamos apenas no método de pagamento utilizado na compra)

public class Pedido {
// Algumas propriedades...
  @JsonProperty("metodo_pagamento")
  private MetodoDePagamento metodoDePagamento;
// Outras propriedades...
}

public class MetodoDePagamento {
// Algumas propriedades...
  @JsonProperty("cartao")
  private CartaoDeCredito cartaoDeCredito;
}

public class CartaoDeCredito {
  @JsonProperty("bandeira")
  private String bandeira;

  @JsonProperty("numero")
  private String numero;
}

Perfeito, agora para exibir as informações do cartão de créditos nós precisamos esconder uma parte dos dados e exibir apenas os 4 primeiros e 4 últimos dígitos.

Não vamos simplesmente adicionar essa lógica na view, certo? Mas o objeto que faz o mapeamento do JSON deve ser um “objeto burro” então a lógica também não pode ficar lá, apesar de fazer todo sentido. Então surgem os “utils”.

public class CartaoDeCreditoUtil {
  public static String formatarNumero(String numeroCartaoDeCredito) {
    return numeroCartaoDeCredito.substring(0, 3) +
              "-xxxx-xxxx-" + numeroCartaoDeCredito.substring(11);
  }
}

A chamada desse código lá na view seria algo assim:

Pedido pedido = servicoPedido.buscaDetalhes(numeroDoPedido)
//...
CartaoDeCreditoUtil.formatarNumero(
  pedido.getMetodoDePagamento().getCartaoDeCredito().getNumero())

Em um time pequeno pode até ser que todos saibam que devem utilizar essa classe para formatar o número do cartão de crédito. Mas imagine isso em um software que é mantido por anos, qual a probabilidade de alguém que chegou agora para dar manutenção saber que a lógica para formatar o cartão de crédito não está junto com o número do cartão? Qual a probabilidade dessa pessoa criar outra classe para manter essa lógica?

Diga ao objeto o que fazer

O exemplo acima é bem simples, mas já mostra os problemas de separar os dados do comportamento de um objeto. Mas e agora, como sair dessa situação?

O primeiro passo é encontrar a fonte de dado para os famigerados métodos da class “util”. Dependendo do seu contexto a refatoração pode ser mais complicada. No exemplo acima podemos simplesmente mover o método para dentro da classe CartaoDeCredito e criar um método getNumeroFormatado:

public class CartaoDeCredito {
// código anterior
  public String getNumeroFormatado() {
    return numero.substring(0, 3) + "-xxxx-xxxx-" + numero.substring(11);
  }
}

No entanto caso o método util dependa de dados que venham de objetos diferentes, pode ficar mais complicado decidir qual deles deve assumir a responsabilidade.

Outra situação complicada é se, apesar de ser um mesmo dado, eles vierem de lugares diferentes. Considerando o exemplo anterior, imagine que mais de uma classe tem um número de cartão de crédito, onde colocar essa lógica?

A opção mais óbvia é duplicar o código, embora ela também vá causar mais problemas. Se a sua linguagem possui alguma forma de mixin, como traits em Scala ou modules em Ruby, é possível extrair esse comportamento e adicioná-lo aonde for necessário.

Uma outra opção também é fazer com esse número de cartão de crédito seja mais do que apenas uma simples String, então poderemos adicionar o comportamento nele e utilizá-lo aonde for necessário lidar com o número do cartão.

Se você quer ir mais afundo no assunto, sugiro o post TellDontAsk de Martin Fowler e o Tell, Don’t Ask da Prag Prog. Esse último artigo vai um pouco além e também fala de outros princípios, que serão detalhados aqui também em outros posts, a Lei de Demeter e a separação entre Comando e Busca (Command/Query).

Compartilhe o texto com seus colegas para ajudá-los a melhorar o código deles também e continue acompanhando os posts da série [Refatorando tudo!] para melhorar ainda mais seu código!

Deixe seus comentário aqui no post ou fale direto comigo no twitter em @marcosbrizeno!