- Evite começar quebrando uma classe ou método grande já com a sua idéia de implementação final. Faça em partes.
- "Faça funcionar, faça certo, melhore."
- Idealmente quebre o código anteriomente grande em pequenas partes e vá refinando cada uma dessas pequenas partes, até chegar ao nível de ter refinado toda a classe ou método por completo.
- Refatoração deve ser feita em pequenas partes para que bugs possam ser descobertos com mais facilidade e também para que seja mais fácil testar as pequenas partes.
- Não exite em renomear coisas que façam sentido que sejam renomeadas.
- Métodos devem pertercem ao objeto ao qual fazem mais uso dos dados, por exemplo se o método X do objeto N recebe um objeto O como argumento e dentro desse objeto O faz uso de dados de O, talvez faça mais sentido o método pertecer a classe O ao invés da classe N.
-
-
Save lcezermf/291d47609f6ce1840a06b3edd8716651 to your computer and use it in GitHub Desktop.
- Quando estiver adicionando funcionalidades, apenas foque em adicionar e testar essas novas funcionalidades, não deve misturar essa atividade com refatoração.
- O mesmo vale para o contrário, quando estiver fazendo refatoração, foque na reestruturação do comportamento já existente e não em adicionar novas funcionalidades.
- Quando código é feito ao longo do tempo e nunca é refatorado, ele degrada com o tempo, o que torna cada vez mais difícil ter clarezar de como está o design do código, se ele faz o que supostamente se propõe a fazer e se está fazendo do modo mais eficiente.
- Quanto mais difícil de identificar o design do código, mais difícil é preserva-lo e mais rapidamente ele irá cair.
- Quanto mais difícil, mais linhas de código, possívelmente bem a mais do que seria necessário para executar o código.
- Utilizar refatoração para melhor código que seja estranho no primeiro momento, tornar aquele código desconhecido mais fácil de ser lido logo de cara
- Tornar o código mais fácil, o torna mais fácil de testar e consequentemente encontrar mais bugs que podem ocorrer.
- Faça funcionar, faça certo, faça melhor.
- Não refatorar mais do que o necessário
- Quando aprendemos uma nova técnica de refatoração é preciso saber que ela não se aplica a todas as situações
- Cuidado a ao refatorar interfaces (métodos) públicos
-
Se o mesmo código é encontrado em dois ou mais métodos na mesma class, é possível utilizar a técnica Extract Method
-
Se o mesmo código é encontrado e duas subclasses de mesmo nível é possível subir para a superclasse o método ou atributos compartilhados pelo método.
-
Se a duplicação ocorre no construtor das subclasses também é possível mover para o construtor da superclasse
Sempre que possível tentar remover a duplicação o mais rápido possível, aplicando a melhor solução para cada caso onde ela pode ocorrer
- Classes com mais de 100 linhas são perigosas
- Aplicar Extract Method ou Extract Class sempre que possível
- Se a refatoração está complicada por conta de variáveis e muitos parâmetros, apicar Replace Temp With Query, Introduce Param Object e Preserve Whole Object.
-
Ocorre quando ao precisar alterar um determinado método de uma classe, você acaba tendo que refatorar vários outros métodos dessa mesma classe, para que aquela alteração possa ser realizada.
-
As razões para isso ocorrer são códigos com arquitetura pobre.
-
Extract Class, Extract Superclass, Extract subclass podem resolver esse problema
-
Ocorre quando para realizar uma alteração em um método de determinada classe é preciso realizar várias alterações pequenas em outras classes que se relacionam com essa primeira.
-
O problema ocorrer por que uma determinada responsabilidade está espalhada por diversas classes.
-
Move Method ou Move Field
- O principal ponto sobre o uso da orientação a objetos é encapsular dados e comportamento para um objeto.
- Um caso de uso clássico onde ocorre Feature Envy é quando determinado método está mais interessado em utilizar métodos ou atributos de outra class, mais do que a si mesmo.
- Move Method e Extract Method podem ser utilizados para resolver o problema
- Em alguns casos a classe que mantem o os dados da classe que mantem o comportamento é propositalmente separada, a vantagem de se utilizar dessa forma deixando a troca de comportamento transparente e dinâmica e quando se utilizam os padrões Visitor e Strategy.
- Grupo de parâmetros que está sendo usado em diferentes partes do software, como parâmetro de diferentes métodos, idealmente devem ser transformados em um único objeto.
- Possível utilizar Param Object para grupar os atributos a um único objeto e preservar esse objeto para que ele seja utilizado como parâmetro.
- Ocorre quando se faz uso de algum tipo primitivo da linguagem para armazenar determinado grupo de informações, ao invés de se criar uma classe própria.
- Evitar sempre que possível fazer case Statements no código, de preferência pelo uso de polimorfismo.
- Ocorre toda vez que ao criar um determinada subclasse, outra subclasse também precisa ser criada.
- Classes que fazem pouco e podem ter seu comportamento inserido em outro lugar, ou classes não utilizadas devem ser apagadas. É possível utilizar
Inline Class
- Criar alguma classe/método para que ela possa ser usada em algum dia, porém esse dia nunca chega. Código acaba sobrando e apenas dificultando a leitura da classe ou do fluxo principal.
method.method_b.method_c.method_d
-> Pode ser evitado com Delegators.
- A classe possui poucos métodos e a maior parte de seu código é apenas para fazer delegações a outras classes, ela n deveria então existir.
- Uma classe usa atributos e métodos privados de outra classe.
- Classes que servem apenas para armazenar dados e não tem nenhum comportamento atrelado, podem ser substituidas por uma Struct.
- Similar ao ISP, sublclasses não devem herdar métodos que não irão usar. Quando superclasse e subclasses acabam servindo para propósitos bem diferentes, não fazendo sentido a herança.