Aula catalogo de refatoracoes
•
1 like•702 views
Descrição das técnicas de refatoração de código. Material de apoio à disciplina SI405, Análise de Sistemas de Informação 2, da Faculdade de Tecnologia da UNICAMP.
Recommended
More Related Content
Similar to Aula catalogo de refatoracoes
Similar to Aula catalogo de refatoracoes (20)
More from Ivan Ricarte
More from Ivan Ricarte (20)
Recently uploaded
Recently uploaded (20)
Aula catalogo de refatoracoes
- 10. Extract Method
- 13. Inline Method
- 14. Inline Method
- 17. ExtractVariable
- 18. ExtractVariable
- 21. InlineTemp
- 22. InlineTemp
- 33. Remove Assignment to Parameters
- 34. Remove Assignment to Parameters
- 37. Replace Method with Method Object
- 38. Replace Method with Method Object
- 47. Move Method
- 48. Move Method
- 51. Move Field
- 52. Move Field
- 55. Extract Class
- 56. Extract Class
- 59. Inline Class
- 60. Inline Class
- 63. Hide Delegate
- 64. Hide Delegate
- 65. https://refactoring.guru/remove-middle-man https://sourcemaking.com/refactoring/remove-middle-man
- 66. https://refactoring.guru/remove-middle-man https://sourcemaking.com/refactoring/remove-middle-man
- 85. Replace DataValue with Object
- 86. Replace DataValue with Object
- 97. Replace Array with Object
- 98. Replace Array with Object
- 105. Change UnidirectionalAssociation to Bidirectional
- 106. Change UnidirectionalAssociation to Bidirectional
- 109. Change BidirectionalAssociation to Unidirectional
- 110. Change Bidirectional Association to Unidirectional
- 113. Replace Magic Number with Symbolic Constant
- 114. Replace Magic Number with Symbolic Constant
- 115. https://refactoring.guru/encapsulate-field https://sourcemaking.com/refactoring/encapsulate-field
- 116. https://refactoring.guru/encapsulate-field https://sourcemaking.com/refactoring/encapsulate-field
- 117. Encapsulate Field
- 118. Encapsulate Field
- 125. ReplaceType Code with Class
- 126. ReplaceType Code with Class
- 129. ReplaceType Code with Subclasses
- 130. ReplaceType Code with Subclasses
- 133. ReplaceType Code with State/Strategy
- 134. ReplaceType Code with State/Strategy
- 137. Replace Subclass with Fields
- 138. ReplaceType Code with State/Strategy
- 143. Ao extrair código condicional para métodos claramente nomeados, você facilita a vida da pessoa que manterá o código mais tarde (como você, daqui a dois meses!). Essa técnica de refatoração também é aplicável para expressões curtas em condições. A string isSalaryDay() é muito mais bonita e mais descritiva do que o código para comparar datas.
- 147. Elimina o código de fluxo de controle duplicado. Combinar vários condicionais que têm o mesmo "destino" ajuda a mostrar que você está fazendo apenas uma verificação complicada que leva a uma ação. Ao consolidar todos os operadores, agora você pode isolar essa expressão complexa em um novo método com um nome que explica a finalidade da condicional.
- 151. O principal benefício desta técnica é remover código duplicado.
- 159. . É difícil descobrir o que cada condicional faz e como, já que o fluxo "normal" de execução de código não é imediatamente óbvio. Para simplificar a situação, isole os casos especiais em condições separadas que terminam imediatamente a execução e retornam um valor nulo se as cláusulas de guarda forem verdadeiras. Com efeito, sua missão aqui é tornar a estrutura plana.
- 164. 1. Se a condicional estiver em um método que executa outras ações também, aplique Extract Method. 2. Para cada subclasse de hierarquia, redefina o método que contém o condicional e copie o código do ramo condicional correspondente para esse local. 3. Exclua este ramo da condicional. 4. Repita a substituição até que a condicional esteja vazia. Em seguida, exclua a condicional e declare o método abstrato.
- 167. O custo de se livrar dessas verificações está em criar uma nova classe.
- 168. 5. Se
- 181. A escolha aqui é entre adicionar um novo parâmetro e adicionar um novo campo privado que contém os dados necessários pelo método. Um parâmetro é preferível quando você precisa de alguns dados ocasionais ou que mudam frequentemente para os quais não há sentido em mantê-los em um objeto o tempo todo. Caso contrário, adicione um campo privado e preencha-o com os dados necessários antes de chamar o método.
- 182. e adicione o parâmetro necessário
- 183. https://refactoring.guru/remove-parameter https://sourcemaking.com/refactoring/remove-parameter
- 184. https://refactoring.guru/remove-parameter https://sourcemaking.com/refactoring/remove-parameter
- 201. • Em vez de uma miscelânea de parâmetros, você vê um único objeto com um nome compreensível. • Se o método precisar de mais dados de um objeto, você não precisará reescrever todos os locais em que o método é usado - apenas dentro do próprio método.
- 205. Como benefício, nós nos livramos dos parâmetros desnecessários e simplificamos as chamadas de método.
- 206. ser utilizado.
- 209. • Código mais legível. Em vez de uma miscelânea de parâmetros, você vê um único objeto com um nome compreensível. • Grupos idênticos de parâmetros espalhados aqui e ali criam seu próprio tipo de duplicação de código: enquanto o código idêntico não está sendo chamado, grupos idênticos de parâmetros e argumentos são constantemente encontrados.
- 225. • Libera o código de um grande número de condicionais para verificar vários códigos de erro. Manipuladores de exceções são uma maneira muito mais sucinta de diferenciar caminhos de execução normais dos caminhos anormais. • As classes de exceção podem implementar seus próprios métodos, contendo, portanto, parte da funcionalidade de tratamento de erros (por exemplo, para enviar mensagens de erro). • Ao contrário das exceções, os códigos de erro não podem ser usados em um construtor, pois um construtor deve retornar apenas um novo objeto.
- 235. • Elimina a duplicação de campos em subclasses. • Facilita a realocação subsequente de métodos duplicados, se existirem, de subclasses para uma superclasse.
- 239. Benefícios:
- 245. https://refactoring.guru/push-down-method https://sourcemaking.com/refactoring/push-down-method
- 246. https://refactoring.guru/push-down-method https://sourcemaking.com/refactoring/push-down-method
- 253. https://refactoring.guru/extract-subclass https://sourcemaking.com/refactoring/extract-subclass
- 254. https://refactoring.guru/extract-subclass https://sourcemaking.com/refactoring/extract-subclass
- 257. https://refactoring.guru/extract-superclass https://sourcemaking.com/refactoring/extract-superclass
- 258. https://refactoring.guru/extract-superclass https://sourcemaking.com/refactoring/extract-superclass
- 259. Você não pode aplicar essa técnica a classes que já possuem uma superclasse.
- 261. https://refactoring.guru/extract-interface https://sourcemaking.com/refactoring/extract-interface
- 262. https://refactoring.guru/extract-interface https://sourcemaking.com/refactoring/extract-interface
- 265. https://refactoring.guru/collapse-hierarchy https://sourcemaking.com/refactoring/collapse-hierarchy
- 266. https://refactoring.guru/collapse-hierarchy https://sourcemaking.com/refactoring/collapse-hierarchy
- 267. No entanto, se a hierarquia de classes tem mais de uma subclasse, é preciso verificar se ao recolher a hierarquia não se violará o Princípio da Substituição de Liskov.
- 271. A duplicação de código nem sempre se refere a casos de copiar / colar simples. Frequentemente, a duplicação ocorre em um nível mais alto, como quando você tem um método para classificar números e um método para classificar coleções de objetos que são diferenciadas apenas pela comparação de elementos. A criação de um método gabarito elimina essa duplicação mesclando as etapas do algoritmo compartilhado em uma superclasse e deixando apenas as diferenças nas subclasses.
- 279. Não use essa técnica se a classe contiver delegação para apenas uma parte dos métodos públicos da classe delegada. Ao fazer isso, você violaria o princípio da substituição de Liskov.
- 280. (this).
- 282. https://refactoring.com/ https://sourcemaking.com/refactoring https://refactoring.guru Refactoring Workbook. Addison-Wesley, 2004. https://industriallogic.com/xp/refactoring/