Working with legacy code

Extract Interface

Utilizar interface ao invés de classes concretas podem ajudar no design, no polimorfismo e especialmente em testes.

public class PayTransaction extends Transaction { public PayTransaction (Database db,

TransactionRecorder log) { public void run() { ... } } }

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.

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.

• A maioria das IDEs atuais traz ferramentas como Extract Interface. Procure usá-las especialmente quando há muitas implementações da classe.

• Cuidado com os métodos estáticos, pois eles não podem fazer parte da interface.

• Procure extrair os métodos de forma incremental à medida que se escreve testes para os mesmos(Testes da classe final).

Passo a passo

• Criar a interface com nome apropriado sem nenhum método.

• Implementar a interface nas classes desejadas

• Substituir as chamadas das classes pela da interface.

• O código não irá compilar enquanto não se extrair as assinaturas dos métodos para interface.

Extract Implementer

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.

Razões

• 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.

• Muitos usam prefixos em interfaces, no entanto, é muito ruim trabalhar com tais nomes pois fere o princípio conhecido como “well-named”.

“This class is too big and I don't want it to get any bigger”

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)

evaluate branchingExpression nextTerm addVariable

causalExpression hasMoreTerms

variableExpression

valueExpression

Em geral, as classe apresentam nomes com prefixos ou sufixos similares como segue abaixo:

RuleEvaluator+ evaluate(string)+ addVariable(string, int)

SymbolTable+ addVariable(string, int)

RuleParser+ parse(string): Expression

TermTokenizer+ nextTerm(): string+ hasMoreTerms: boolean

Expression+ evaluateWith(SymbolTable)

Heurística

• Group methods – agrupar métodos por nome ou funcionalidade. É pouco custoso e facilita o entendimento em grandes classes.

• 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.

Heurística

• 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.

• 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.

Heurística

• Look for the Primary Resposibility – Tente descrever uma classe em uma única fase.

• When all else fails, do some Scratch Refactoring.

• 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.

Feature sketch• É um esquema muito útil e simples

para descobrir o relacionamento interno entre os métodos e atributos das classes.

• Agrupa-se os métodos e atributos por similaridade de nome ou funcionalidade.

Reservation- duration: int- dailyRate: int- date: Date- customer: Costumer- fees: List+ extend(days)+ extendForWeek()+ addFee(FeeRider)<<delegates>>- getPrincipalFee(): int+ getTotalFee() :int+ getAdditionalFee(): int

duration

getPrincipalFee

extend

dailyRateextendForWeek

date

customer

getTotalFeegetAdditionalFees

fees

addFee

Esquema da classe Reservation

duration

getPrincipalFee

extend

dailyRate

extendForWeek

date

customer

getTotalFeegetAdditionalFees

fees

addFee

Métodos aglomerados em Reservation

duration

getPrincipalFee

extend

dailyRate

extendForWeek

date

customer

getTotalFee

getAdditionalFees

fees

addFee

Métodos aglomerados em outra classe

Interface segragation Principle

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.

...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.

Ao adicionar novas funcionalidades lembre-se...

Working with Legacy Code by Michael Feather

Recomendação do autor:• Livro Refactoring: Improving the Design of Existing Code

(Martin Fowler)