Working with legacy code 3

411 visualizações

Publicada em

A presentation about Michael Feathers' Book "Working with legacy code 3"

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
411
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Working with legacy code 3

  1. 1. Working with legacy code
  2. 2. Extract Interface <ul><li>Utilizar interface ao invés de classes concretas podem ajudar no design, no polimorfismo e especialmente em testes. </li></ul>
  3. 3. <ul><li>public class PayTransaction extends Transaction { </li></ul><ul><li>public PayTransaction ( Database db , TransactionRecorder log ) { </li></ul><ul><li>public void run() { </li></ul><ul><li>... </li></ul><ul><li>} </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>
  4. 4. <ul><li>Parâmetros como Database db e TransactionRecorder log podem ser opcionais em um testes, na verdade criaremos superclasses com uma implementação simples ou vazia dos métodos existentes. </li></ul><ul><li>Também as interface costumam melhorar o modelo do código, pois pensa-se primeiro nos métodos necessários sem sua implementação e nos parâmetros necessário. </li></ul>
  5. 5. <ul><li>A maioria das IDEs atuais traz ferramentas como Extract Interface. Procure usá-las especialmente quando há muitas implementações da classe. </li></ul><ul><li>Cuidado com os métodos estáticos, pois eles não podem fazer parte da interface. </li></ul><ul><li>Procure extrair os métodos de forma incremental à medida que se escreve testes para os mesmos(Testes da classe final). </li></ul>
  6. 6. Passo a passo <ul><li>Criar a interface com nome apropriado sem nenhum método. </li></ul><ul><li>Implementar a interface nas classes desejadas </li></ul><ul><li>Substituir as chamadas das classes pela da interface. </li></ul><ul><li>O código não irá compilar enquanto não se extrair as assinaturas dos métodos para interface. </li></ul>
  7. 7. Extract Implementer <ul><li>Mesma finalidade de Extract Interface, no entanto, a classe se tornará a Interface e a será criada uma cópia idêntica da classe atual, mas com outro nome. </li></ul>
  8. 8. Razões <ul><li>Em geral o nome da classe atual é o nome ideal para interface, pois é nela que contém a “idéia”, e a classe é como a idéia será executada. </li></ul><ul><li>Muitos usam prefixos em interfaces, no entanto, é muito ruim trabalhar com tais nomes pois fere o princípio conhecido como “well-named”. </li></ul>
  9. 9. “ This class is too big and I don't want it to get any bigger”
  10. 10. RuleParser - current: string - variables: Hasmap - currentPosition: int + evaluate(string): int + branchExpression(Node left, Node right): int + causalExpression(Node left, Node right): int + variableExpression(Node node): int + nextTerm(): string - hasMoreTerms(): boolean + addVariable(string name, int value)
  11. 11. Em geral, as classe apresentam nomes com prefixos ou sufixos similares como segue abaixo: evaluate branchingExpression nextTerm addVariable causalExpression hasMoreTerms variableExpression valueExpression
  12. 12. RuleEvaluator + evaluate(string) + addVariable(string, int) SymbolTable + addVariable(string, int) RuleParser + parse(string): Expression TermTokenizer + nextTerm(): string + hasMoreTerms: boolean Expression + evaluateWith(SymbolTable)
  13. 13. Heurística <ul><li>Group methods – agrupar métodos por nome ou funcionalidade. É pouco custoso e facilita o entendimento em grandes classes. </li></ul><ul><li>Look at Hidden Methods – Classes grandes costumam ter diversos métodos privados, se necessário converta-os em públicos para testes. Muitas vezes chega-se a conclusão de criar uma nova classe com esses métodos. </li></ul>
  14. 14. Heurística <ul><li>Look for decisions that can change – foque nas tomadas de decisões dos métodos já criados, verifique se usa conexão com banco de dados, grandes APIs, hard-coded. </li></ul><ul><li>Look for internal relationships – Em geral classes muito grandes com diversos atributos e métodos não são chamam um pelo outro em todos os lugares, então, conclui que pode-se descobrir quais métodos devem ser testados. </li></ul>
  15. 15. Heurística <ul><li>Look for the Primary Resposibility – Tente descrever uma classe em uma única fase. </li></ul><ul><li>When all else fails, do some Scratch Refactoring. </li></ul><ul><li>Focus on the current work – Mude apenas o necessário. Não se trata de uma reforma completa, apenas uma refatoração suficiente para que haja maior sentimento de confiança na alteração real. </li></ul>
  16. 16. Feature sketch <ul><li>É um esquema muito útil e simples para descobrir o relacionamento interno entre os métodos e atributos das classes. </li></ul><ul><li>Agrupa-se os métodos e atributos por similaridade de nome ou funcionalidade. </li></ul>
  17. 17. Reservation - duration: int - dailyRate: int - date: Date - customer: Costumer - fees: List + extend(days) + extendForWeek() + addFee(FeeRider)<<delegates>> - getPrincipalFee(): int + getTotalFee() :int + getAdditionalFee(): int
  18. 18. Esquema da classe Reservation duration getPrincipalFee extend dailyRate extendForWeek date customer getTotalFee getAdditionalFees fees addFee
  19. 19. duration getPrincipalFee extend dailyRate extendForWeek date customer getTotalFee getAdditionalFees fees addFee Métodos aglomerados em Reservation
  20. 20. duration getPrincipalFee extend dailyRate extendForWeek date customer getTotalFee getAdditionalFees fees addFee Métodos aglomerados em outra classe
  21. 21. Interface segragation Principle <ul><li>Grandes classes que implementam interfaces geralmente não usufruem de todos os métodos, então, é mais interessante criar diversas interfaces menores e implementar quantas forem necessárias nas classes. </li></ul>
  22. 22. Ao adicionar novas funcionalidades lembre-se... ...que ao adicionar novas funcionalidades, acima de tudo, o design atual já funcionava. Sejam classes grandes ou sem padrões, elas atualmente exercem funções e muitas vezes de maneira eficiente.
  23. 23. <ul><li>Working with Legacy Code by Michael Feather </li></ul><ul><li>Recomendação do autor: </li></ul><ul><ul><ul><li>Livro Refactoring: Improving the Design of Existing Code (Martin Fowler) </li></ul></ul></ul>

×