Refatoração POO PDF

Programao Orientada a Objetos
Padres de Projeto
Refatorao
Guinther Pauli
Arquiteto de Software - MVP
Sobre o autor
Guinther Pauli - Arquiteto de Software certificado pela Microsoft, Professor de Ps-
Graduao, Membro Editorial das Revistas .NET Magazine Brasil e ClubeDelphi, as
maiores publicaes do pas em seus segmentos - Certificado oficial MCP, MCAD,
MCSD.NET, MCTS, MCPD (ASP.NET C# - 4.0) - Certificado Delphi: 3, 5, 6, 7, 2005, 2006,
Delphi para Web, Delphi para Linux. MVP Most Valuable Professional. Foi arquiteto e
desenvolvedor do sistema de doaes on-line do projeto Criana Esperana da Rede
Globo / Unesco. Beta Test de vrias verses do Delphi, palestrante em 5 edies da
Borland Conference, maior evento de desenvolvedores do pas. Ministra treinamentos
corporativos para empresas e universidades, j tendo treinado mais de 5 mil
profissionais em todo Brasil e exterior, incluindo grandes empresas como SONY,
UNICAMP e KBR. Autor de mais de 1000 vdeo-aulas de ensino a distncia, publicou mais
de 130 artigos, alm do livro Delphi Programao para Banco de Dados e Web. Fez a
cobertura de grandes eventos no exterior, como o TechEd da Microsoft e a BorCon da
Borland americana. Desenvolve em Delphi h 17 anos e 12 anos em .NET / C#. Bacharel
em Sistemas de Informao e Mestrando do Programa de Ps-Graduao em
Informtica na UFSM - Universidade Federal de Santa Maria - RS. reas de interesse e
pesquisa: Engenharia de Software, Programao Orientada a Objetos, Padres de
Projeto e Refatorao.
Bibliografia
Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 3

Roteiro
Bad Smells (Code Smells)

Cdigo Limpo (Code Clean)
Padres de Projeto (Design Patterns)
Refatorao (Refactoring)
Refatorao para Padres

Bad Smells (Code Smells)

Bad Smells
De acordo com Kent Beck, bad smells (maus

cheiros) so estruturas no cdigo que sugerem a
possibilidade de refatorao. Alguns exemplos de
problemas em estruturas de cdigo so: cdigo
duplicado.

Bad Smells
Rigidez uma alterao em um ponto do cdigo requer

alteraes em cascata (dependncias);
Fragilidade A modificao de um ponto do cdigo
quebra outras funcionalidades;
Complexidade Arquitetura muito complexa pois foi
preparada para manipular qualquer tipo de possibilidade;
Duplicao Cdigo redundante, duplicado;
Legibilidade Cdigo difcil de compreender e entender.

Cdigo Duplicado (Duplicated Code)
Este provavelmente um dos problemas mais graves

no cdigo. Podem ser duas expresses idnticas em
dois mtodos na mesma classe, ou duas classes no
associadas. Essa duplicao pode ser eliminada
aplicando-se a refatorao Extrair Mtodo (Extract
Method). Nesse caso, o cdigo implementado uma
nica vez e chamado no local de origem onde estava o
cdigo duplicado. Se o cdigo duplicado encontra-se
em duas classes distintas, pode-se aplicar a
refatorao Extrair Classe(Extract Class).
Mtodo Longo (Long Method)
Consiste de um mtodo com uma implementao de lgica

com vrias, dezenas ou at centenas de linhas de cdigo. O
ideal seria criar mtodos com no mximo dez linhas de
cdigo, podendo ser inclusive de uma a cinco. Vrios
problemas podem ser originados da implementao de
mtodos longos. Primeiro, pode existir cdigo duplicado.
Segundo, ser difcil reaproveitar parte do cdigo em outro
local. A soluo dividir o mtodo longo em mtodos
menores, usando-se a refatorao Extrair Mtodo (Extract
Method).

Classe Larga (Large Class)
Uma boa prtica da programao orientada a objetos

sugere que uma classe deve ter uma nica
responsabilidade (princpio da responsabilidade
nica). Quando uma classe possui muitas instncias no
cdigo, isso sugere que ela est fazendo muito, ou
pelo menos realizando trabalho que deveria ser feito
por outras classes. Algumas refatoraes podem
ajudar a reduzir classes longas, como por exemplo,
Extrair Classe (Extract Class), Extrair Subclasse (Extract
subclass), entre outras.
Lista de Parmetros Longa (Long
Parameter List)
Um mtodo que recebe muitos parmetros sugere que classes

possam estar compartilhando muita informao, ou ainda, dados
globais. Se um mtodo com uma longa lista de parmetros est
sendo chamado em vrios locais do cdigo, uma mudana em um
deles pode desencadear uma cadeia muito grande de alteraes
em vrios locais do cdigo. Algumas refatoraes podem ajudar a
resolver esse problema, por exemplo, a Substituir Parmetro por
Mtodo (Replace Parameter with Method) (Fowler, 1999) e
Introduzir Parmetro Objeto (Introduce Parameter Object)
(Fowler, 1999). Neste ltimo caso, por exemplo, uma longa lista
de parmetros se resume a uma nica estrutura (classe, por
exemplo), que internamente define atributos.

Mudana Divergente (Divergent
Change)
Ocorre quando uma classe alterada geralmente de

diferentes formas por diferentes motivos.
Normalmente, uma mudana requer a alterao de
vrias classes. Nesse caso, uma boa soluo seria isolar
ou encapsular cdigo passvel de mudana para que
comporte a mudana em um nico local, quando
necessria.

Tiro Cirrgico (Shotgun Surgery)
Esta situao o oposto de Mudana Divergente

(Divergent Change). Em uma pequena mudana de
cdigo, necessrio realizar vrias pequenas
mudanas em vrias classes.

Recurso Invejoso (Feature Envy)
Ocorre quando um mtodo realiza a maioria das suas

funes consultando outros mtodos ou mesmo
outros objetos, a fim de obter dados, realizar clculos,
lgica etc.

Dados Agregados (Data Clumps)
Ocorre normalmente quando dados costumam

aparecer juntos em vrias situaes: campos em
classes, em lista de parmetros em assinaturas de
mtodos etc. Uma soluo seria aplicar a refatorao
Introduzir Parmetro Objeto (Introduce Parameter
Object).

Obsesso Primitiva (Primitive
Obsession)
Existem basicamente dois tipos de dados na maioria das

linguagens: os primitivos e as estruturas (normalmente
classes, formadas a partir da composio de outros tipos
primitivos). A obsesso primitiva ocorre normalmente com
desenvolvedores com pouca experincia tcnica em
orientao a objetos. Refatoraes como Substituir Dado
por Objeto (Replace Data with Object) e Substituir Cdigo de
Tipo por Estado / Estratgia (Replace Type Code with State /
Strategy) podem ajudar a solucionar problemas com
obsesso primitiva.

Sentenas switch (Switch
Statements)
Testar vrias possibilidades com sentenas switch

(case) tende a duplicar cdigo. Se um novo teste for
necessrio na sentena, para comportar uma nova
possibilidade, e esse teste for feito em vrios locais,
ento vrias alteraes sero necessrias. Muitas
vezes os testes podem ser substitudos por
polimorfismo, usando a refatorao Substituir
Condicional por Polimorfismo (Replace Conditional with
Polymorphism) (Fowler, 1999).
Hierarquia de Herana Paralela
(Parallel Inheritance Hierarchies)
Nesse caso, cada vez que uma classe se torna

subclasse de outra, tambm necessrio criar uma
subclasse de outra classe (pois existem hierarquias
paralelas). As refatoraes Mover Mtodo (Move
Method) e Mover Campo (Move Field) ajudam a
minimizar problemas relacionados a este bad smell.

Classe Preguiosa (Lazy Class)
Cada classe criada no sistema de software tem um

custo para ser mantida e evoluda. Classes que no
esto fazendo o suficiente para pagarem seu prprio
custo devem ser eliminadas. A refatorao Recolher
Hierarquia (Collapse Hierarchy) pode minimizar
problemas associados a classes preguiosas.

Generalidade especulativa
(Speculative Generality)
Este problema ocorre quando se projeta uma soluo

genrica para uma possvel situao que
possivelmente nunca ocorrer, tornando objetos
flexveis o suficiente para tratar qualquer tipo de
situao, por exemplo, criando-se classes abstratas
que no realizam muito. A refatorao Recolher
Hierarquia (Collapse Hierarchy) pode minimizar
problemas associados generalidade.

Campo Temporrio (Temporary Field)
Muitas vezes um objeto tem sua varivel de instncia

configurada somente sobre certas circunstncias. Tal
cdigo difcil de entender. Um exemplo ocorre
quando um algoritmo depende de uma srie de
variveis. A refatorao Extrair Classe (Extract Class)
pode minimizar problemas associados essas
variveis pobres.

Cadeia de Mensagens (Message
Chains)
Ocorre quando um cliente consulta um objeto a partir

de outro objeto, que por sua vez repassa a consulta a
outro objeto, que consulta outro, e assim por diante,
causando uma cadeia de chamadas. Qualquer
mudana nos relacionamentos intermedirios pode
ocasionar grandes problemas. As refatoraes Extrair
Mtodo (Extract Method) (Fowler, 1999) e Esconder
Delegao (Hide Delegate) (Fowler, 1999) minimizam
problemas desse tipo.
Homem do Meio (Middle Man)
O encapsulamento um dos principais recursos da

programao orientada a objetos, a habilidade de
esconder detalhes internos do resto do mundo. A
delegao ocorre quando uma classe recebe
chamadas e utiliza um objeto interno para realizar a
maioria de suas funes (delegao). A refatorao
Remover Homem do Meio (Remove Middle Man)
(Fowler, 1999) permite reduzir este problema.

Intimidade inadequada
(Inappropriate Intimacy)
Muitas vezes classes se tornam demasiadamente

ntimas e perdem muito tempo investigando partes
privadas da prpria classe. As refatoraes Mover
Mtodo (Move Method) e Mover Campo (Move Field)
ajudam a separar partes para reduzir essa intimidade.

Classes Alternativas com Diferentes Interfaces
(Alternative Classes with
Different Interfaces)
Ocorre com mtodos que fazem a mesma coisa, mas

com diferentes assinaturas. As refatoraes Mover
Mtodo (Move Method) e Extrair Superclasse (Extract
Super Class) ajudam a resolver esse tipo de problema.

Biblioteca de Classes Incompleta
(Incomplete Library Class)
Objetos so o princpio bsico da reutilizao de

cdigo. Bibliotecas de classes realizam boa parte de
tarefas comuns usando esse conceito. Porm,
normalmente no se pode alterar uma biblioteca base
de classes. A refatorao Introduzir Mtodo
Estrangeiro (Introduce Foreign Method) permite
simular a incluso de um mtodo em uma classe que
no pode ser estendida nem modificada.

Classe de Dados (Data Class)
Classes de dados normalmente contm muitos

campos pblicos para representarem seus dados, e
nada mais. Esse tipo de classe frequentemente
trabalha como container de dados que so utilizados e
repassados para outras classes. A refatorao
Encapsular Campo (Encapsulate Field) permite
encapsular o acesso a esses campos.

Legado Recusado (Refused Bequest)
Classes herdam mtodos e dados de classes

superiores, porm muitas vezes no precisam de
todos os dados e comportamentos herdados para
funcionar. Provavelmente h um problema na
hierarquia. As refatoraes Descer Mtodo / Campo
(Push down Method / Field) (Fowler, 1999) permite
deslocar mtodos e campos para classes mais
especficas, mantendo nas classes superiores somente
o que realmente comum a toda hierarquia.
Comentrios (Comments)
Comentrios so bons, porm, um cdigo com muitos

comentrios um forte indcio que ele est difcil de
entender. Talvez seja mais apropriado dar nomes mais
sugestivos a mtodos, deixando mais claras suas
responsabilidades, usando a refatorao Renomear
Mtodo (Rename Method) (Fowler, 1999).

Code Clean

Code Clean
O que um cdigo limpo:

Simples;
Eficiente;
Direto;
Elegante;
Sem duplicidade;
Feito com cuidado;
Que faz uma coisa;

Code Clean
Nomes significativos, que revelam sua inteno;

Expressa o que faz, por que existe, como usado;
Nomes pronunciveis;
Notao hngara, tipo no precisa estar no nome;
Nomes de classes so substantivos;
Nomes de mtodos so verbos;
Assessores devem ter get e set;

Code Clean
Mtodos pequenos (5 ou 10 linhas);

Linhas de at 100 chars;
Mtodos devem realizar uma nica tarefa;
Cuidar com lista longa de parmetros;
Classes pequenas (200 linhas);
Seguir o princpio da responsabilidade nica;
Cuidar o acoplamento entre classes (dependncias);
Refatore ao invs de comentar;

Padres de Projeto

Introduo
Chrisptopher Alexander, um arquiteto, professor e

comentarista social, afirma: cada padro descreve
um problema no nosso ambiente e o cerne de sua
soluo, de tal forma que voc possa usar essa
soluo mais de um milho de vezes, sem nunca faz-
lo da mesma maneira.

Introduo
Usar padres de projeto torna mais fcil reutilizar projetos
e arquiteturas bem-sucedidas. Expressar tcnicas testadas
e aprovadas as torna mais acessveis para os
desenvolvedores de novos sistemas. Os padres de projeto
ajudam a escolher alternativas de projeto que tornam um
sistema reutilizvel e evitar alternativas que comprometam
a reutilizao. Os padres de projeto podem melhorar a
documentao e a manuteno de sistemas ao fornecer
uma especificao explcita de interaes de classes e
objetos e o seu objeto subjacente. Em suma, ajudam um
projetista a obter mais rapidamente um projeto adequado.
Introduo
Padres ajudam a solucionar problemas de projeto, por

exemplo, quando estamos procurando objetos apropriados
em um sistema orientado a objetos. Um objeto empacota
tantos os dados quanto os procedimentos que operam
sobre eles. Os procedimentos so chamados de mtodos ou
operaes. Um objeto executa uma operao quando ele
recebe uma solicitao (ou mensagem) de um cliente.

Introduo
As solicitaes so a nica maneira de conseguir que um

objeto execute uma operao. As operaes so a nica
maneira de mudar os dados internos de um objeto. Por
causa dessas restries, diz-se que o estado interno de um
objeto est encapsulado; ele no pode ser acessado
diretamente e sua representao invisvel do exterior do
objeto.

Introduo
A parte difcil sobre projeto orientado a objetos a

decomposio de um sistema em objetos. A tarefa difcil
porque muitos fatores entram em jogo: encapsulamento,
granularidade, dependncia, flexibilidade, desempenho,
evoluo, reutilizao, e assim por diante. Todos
influenciam a decomposio, e frequentemente, formas
conflitantes (Gamma et al., 1995).

Introduo
As metodologias de projeto orientado a objetos favorecem

muitas abordagens diferentes. Voc pode escrever uma
descrio de um problema, separar os substantivos e os
verbos e criar classes e operaes correspondentes. Ou
voc pode se concentrar sobre as colaboraes e
responsabilidades no seu sistema. Ou ainda, poder
modelar o mundo real e, na fase de projeto, traduzir os
objetos encontrados durante a anlise. Sempre haver
desacordo sobre qual a melhor abordagem.

Introduo
Muitos objetos num projeto provm do modelo de anlise.

Porm, nem todos estes objetos acabam tendo uma
representao simples como no mundo real. So
representadas de mais baixo nvel. Os padres de projeto
ajudam a identificar abstraes menos bvias bem como os
objetos que podem captur-las. Por exemplo, objetos que
processam um algoritmo no existem na natureza, mas so
cruciais em projetos flexveis.

Introduo
Alm disso, os objetos podem variar em tamanho e nmero

e podem representar qualquer coisa. Como decidir o que
deve ser um objeto? Os padres de projeto tambm ajudam
nesse sentido. Por exemplo, o padro Faade descreve
como representar subsistemas inteiros como objetos.
Outros padres descrevem maneiras especficas de como
decompor um objeto em objetos menores. O Abstract
Factory e Builder fornecem objetos cujas nicas
responsabilidades so criar outros objetos (Gamma et al.,
1995).
Introduo
Padres de Projeto tambm ajudam a especificar interfaces de objetos.

As interfaces so fundamentais em sistemas orientados a objetos. No
existe nenhuma maneira de saber algo sobre um objeto ou de pedir que
faa algo sem intermdio de sua interface. A interface nada diz sobre a
implementao de um objeto, com isso objetos esto livres para
implementar as solicitaes de diferentes maneiras, ao mesmo tempo
em que podem ser totalmente substitudos por outros objetos que
implementam a mesma interface, realizando as mesmas operaes, de
forma diferente (tcnica conhecida como polimorfismo). Isso reduz
significativamente o acoplamento entre classes, promovendo a
reutilizao. Os padres de projeto ajudam a definir interfaces para
identificao de seus elementos-chave e pelos tipos de dados que so
enviados atravs de uma interface.
Introduo
Padres de projeto tambm ajudam a especificar a

implementao de objetos. Uma implementao definida
por uma classe. Ela representa os dados que o objeto deve
conter bem como suas operaes. Novas classes podem ser
criadas a partir da herana de outras classes. Nesse caso, diz-
se que as classes descendentes so as subclasses, e a classe
base, a superclasse. Quando uma classe superior apenas
especifica uma interface comum para todas as suas
subclasses, ela chamada de classe abstrata. As classes que
herdam dela e efetivamente realizam as operaes so
chamadas de classes concretas.
Introduo
Nesse ponto importante diferir entre herana de classe

versus herana de interface. Ao herdar de uma interface,
uma classe apenas assume que ir implementar as
operaes por elas definida. Diferentemente, uma classe
abstrata pode tambm conter um comportamento padro
para ser herdado por suas subclasses, o que no pode ser
feito somente com interfaces.

Introduo
Isso remete a uma das principais boas prticas da

programao orientada a objetos, a programao para
interfaces, e no para uma implementao. Padres de
projeto ajudam a seguir esta prtica, ao promoverem o
baixo acoplamento entre classes usando solues baseadas
em interfaces. Clientes com isso conhecem pouco sobre
tipos especficos que usam.

Introduo
Padres de projeto tambm ajudam a identificar quando

utilizar herana ou composio, um dos princpios
fundamentais da programao orientada a objetos para
reaproveitamento de cdigo. A composio uma
alternativa herana, conhecida como herana de caixa
preta, j que os detalhes do objeto herdado no ficam
expostos ao mundo externo. J a herana mais rgida, a
classe que herda estar dependendo da hierarquia de tipos
definida, tendo pouca flexibilidade. Nesse caso, prefervel
usar composio herana.

Introduo
A chave para a maximizao da reutilizao est na

antecipao de novos requisitos e mudanas nos requisitos
existentes e em projetar sistemas de modo que eles possam
evoluir de acordo. Padres ajudam a projetar sistemas de
software melhor preparados para mudanas.

Introduo
A chave para a maximizao da reutilizao est na

antecipao de novos requisitos e mudanas nos requisitos
existentes e em projetar sistemas de modo que eles possam
evoluir de acordo. Padres ajudam a projetar sistemas de
software melhor preparados para mudanas.

Padres GoF
Os padres "GoF" so organizados em 3 famlias :

Padres de criao : relacionados criao de objetos;
Padres estruturais : tratam das associaes entre
classes e objetos;
Padres comportamentais : tratam das interaes e
divises de responsabilidades entre as classes ou
objetos;

Padres de Criao
Abstract Factory
Builder
Factory Method
Prototype
Singleton

Padres Estruturais
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Padres Comportamentais
Chain of Responsibility Observer

Command State
Iterator Strategy
Mediator Template Method
Memento Visitor

Excesso de engenharia
Um sistema que projetado o mais flexvel ou sofisticado

quanto deveria ser, feito em demasia. Programadores
projetam em excesso hoje, normalmente usando dezenas
de padres de projeto, pois acreditam conhecer os futuros
requisitos do sistema, tornando-os mais fceis de acomodar
amanh. A menos que programadores sejam videntes, as
previses erradas podem resultar em perda de tempo e
dinheiro preciosos. Normalmente programadores tentam
antecipar necessidades que nunca se materializam. Novos
programadores vo ser obrigados a trabalhar em uma
estrutura de cdigo complexa, mais complicada do que
deveria ser.
Projeto antecipado com padres
Um grande projeto antecipado ocorre quando um sistema

de software projetado em um primeiro momento para
um grande conjunto de requisitos que podem futuramente
mudar, serem descartados ou postergados para uma futura
verso do sistema. Muito tempo gasto pensando em um
projeto que mais elegante ou sofisticado do que
precisaria ser.

Escassez de engenharia
Projeto em escassez mais comum que projeto em excesso.

Softwares mal projetados podem ocorrer por diversas razes:
Falta de tempo;
Falta de conhecimento sobre um bom projeto de software;
Necessidade de se adicionar rapidamente funcionalidades a
sistemas existentes;
Projetos sendo executados em paralelo.
Em curto prazo projetar em escassez reduz custos. Ao longo do
tempo, torna-se caro, muito caro. O cdigo se torna difcil de
manter, muitas vezes uma baguna que nem possvel de ser
mantida, quem dir evoluda. Muitas vezes, gerentes sem
conhecimento tcnico nestes problemas, explicam que a
organizao ser mais competitiva e bem sucedida se no
consertar o que no est quebrado.
Escassez de engenharia
Projeto em escassez de forma contnua leva a um ritmo de

desenvolvimento de software que pode ser descrito como rpido,
normal, lento, mais lento, extremamente lento, algo como:
A verso 1.0 do sistema entregue rapidamente;
A verso 2.0 do sistema entregue, o cdigo ruim retarda o
desenvolvimento;
medida que se entregam novas verses, mais tempo necessrio
para implementar novas funcionalidades ou corrigir bugs existentes,
pois o cdigo ruim se multiplica, as pessoas comeam a perder f no
sistema, nos programadores, e at mesmo no processo que levou todo
mundo a esta posio; Neste ponto muito comum haver uma
rotatividade de profissionais na equipe, o que piora ainda mais a
situao;
Em algum momento, depois da verso 4.0, a equipe percebe que no
existe mais uma soluo, o caos j est generalizado, ento comea a
estudar a opo de uma reescrita total do sistema.
Dbito de Projeto (Design Debt)
A linguagem tcnica de refatorao no comunica

efetivamente com a maioria das gerncias. Melhorar um
projeto existente sem modificar o comportamento externo
observvel, o que envolve custo e tempo, no ser visto
com bons olhos por gerentes. A metfora financeira do
dbito de projeto uma boa soluo. O dbito de projeto
ocorre quando o desenvolvedor no realiza
consistentemente trs coisas: remover duplicao,
simplificar cdigo e deixar clara a sua inteno. Humanos
no so perfeitos, no escrevem corretamente da primeira
vez, e naturalmente um dbito de projeto acumulado. A
questo , quando esse dbito ser pago?
Dbito de Projeto
Devido ignorncia ou o comprometimento a no

consertar aquilo que no est quebrado, muitos
programadores e equipes gastam pouco tempo para pagar
esse dbito, como resultado, criam uma grande confuso,
que leva a sistemas mal projetados, de difcil compreenso
e manuteno. Em termos financeiros, quando um dbito
no pago, taxas vo se acumulando na forma de juros,
pior eles se tornam e mais difcil ser o pagamento. Juros
compostos se acumulam e, medida que o tempo passa,
livra-se dessa dvida torna-se um sonho impossvel. Assim
tambm com o dbito de projeto.

Dilema
Excesso de engenharia um problema,

pois geralmente no se pode aplicar
padres de forma antecipada;
Escassez de engenharia a falta da
aplicao de padres;
Ento, como e quando aplicar padres
de projeto?

Refatorao

Refatorao
Uma premissa bsica de qualquer sistema de software do mundo

real a necessidade de evoluir. medida que estes so evoludos,
modificados e adaptados de acordo com novas exigncias, o cdigo
e outros artefatos envolvidos se tornam mais complexos e se
afastam de seu objetivo original, podendo diminuir sua qualidade.
Em muitos projetos, boa parte do custo dedicada sua
manuteno. Boas metodologias de desenvolvimento de software e
ferramentas no resolvem este problema, pois sua utilizao
normalmente auxilia na acelerao no desenvolvimento, o que faz
com que as empresas consequentemente aumentem o nmero de
requisitos a serem implementados dentro do mesmo espao de
tempo, tornando os sistemas de software ainda mais complexos.
Refatorao
Para lidar com esse alto ndice incremental de

complexidade, que geram custos, existe a necessidade
de se usar tcnicas que facilitem a manutenibilidade e
legibilidade, melhorando a qualidade interna do
sistema de software. Uma das tcnicas usadas para
solucionar esse problema conhecida como
reestruturao, ou no caso especfico da programao
orientada a objetos, Refatorao.

Refatorao
Refatorao o processo de modificar um sistema de software

sem alterar o comportamento externo do cdigo, melhorando
sua estrutura interna. uma forma disciplinada de limpar
minimizando as chances de introduzir erros. Em essncia, quando
voc refatora, voc est melhorando o design do cdigo depois
de ter sido escrito. Um bom projeto deveria vir em primeiro lugar,
a seguir a sua codificao. Com a evoluo do sistema de
software, mudanas ocorrero, e a sua estrutura e integridade
original diminuem.

Refatorao
Essa reestruturao tambm definida como a

transformao de uma forma de representao para outra,
no mesmo nvel relativo de abstrao, enquanto preserva o
comportamento externo do sistema (funcionalidade e
semntica). Essas transformaes podem melhorar a
estrutura do projeto. Embora a reestruturao crie novas
verses que implementam ou propem mudanas no
objetivo final do sistema, normalmente no envolvem
modificaes referentes a novos requisitos. No entanto,
podem conduzir a observar melhor o objetivo do sistema, j
que sugerem mudanas que poderiam melhorar seus
aspectos.

Refatorao
Nesse sentido, necessrio identificar locais nos artefatos

de software que precisam ter sua estrutura transformada,
seja para melhorar sua legibilidade, melhorar o projeto,
tornar mais simples de evoluir e de manter. Tais estruturas
passveis de refatorao so tambm conhecidas como
Bad Smells, ou problemas. Um bad smell sugere que
existem deficincias ou limitaes nos artefatos que podem
ser sanadas ou melhoradas, porm necessrio que a
aplicao continue apresentando o mesmo
comportamento externo aps a transformao interna.

Refatorao
Outro ponto a ser considerado no estudo da

programao orientada a objetos o uso de padres
de projeto, amplamente utilizados no projeto de
arquiteturas de software, pois representam solues
gerais, reutilizveis, testadas e documentadas,
resolvendo problemas recorrentes de programao
orientada a objetos. Muitas vezes, no entanto,
padres de projeto tendem a ser utilizados de forma
antecipada em um projeto.
Refatorao
Refatorao processo inverso desta prtica. Voc

parte de um mau design (um verdadeiro caos),
refatora e obtm um cdigo bem projetado. Cada
refatorao consiste de um passo simples, pequeno.
Voc move um campo para outra classe, move um
mtodo para uma classe superior na hierarquia. Cada
pequeno passo melhora o design do cdigo,
mantendo o comportamento externo.

Refatorao
Existem vrias motivaes para o uso de refatoraes.

Primeiro, elas tornam mais fcil a adio de novo
cdigo. Quando se inclui uma nova funcionalidade em
um sistema de software, existem basicamente duas
opes: programar rapidamente sem se preocupar o
quo bem se encaixa no projeto existente, ou pode-se
modificar o projeto existente a fim de melhor
acomodar a funcionalidade. No primeiro caso, ocorre
um dbito de projeto, o qual pode ser pago mais tarde
com refatorao.
Refatorao
Segundo, as refatoraes melhoraram um projeto de

cdigo existente, no momento que tornam o cdigo
mais simples, claro e mais fcil de trabalhar, manter e
evoluir. A refatorao contnua envolve procurar
constantemente por problemas e remov-los
imediatamente. Habituar-se ao higinico hbito de
refatorar continuamente, resultar em cdigo sempre
limpo.

Refatorao
E finalmente, refatoraes ajudam a se obter um

melhor entendimento do cdigo. Se um cdigo est
difcil de ser compreendido, programadores
normalmente comentam este cdigo para tornar mais
clara sua inteno. Se o cdigo no est claro, o
problema precisa ser removido atravs de
refatorao.

Refatorao - Fundamentos
Pode-se ento definir o termo refatorar (verbo) como

reestruturar um sistema de software aplicando-se uma
srie de refatoraes sem modificar seu
comportamento observvel. Nesse caso, refatorao
(nome), uma mudana feita na estrutura interna de
um sistema de software para torn-lo mais fcil de
entender e modificar sem alterar o comportamento
externo observvel.

Um bom contraste com refatorao performance e

otimizao. Assim como refatorao, melhorar a
performance e otimizao de um sistema de software
no afeta o comportamento observvel. No entanto,
tm propsitos diferentes, pois melhorar a
performance pode tornar o cdigo mais fcil de
entender. Para o usurio final, um sistema de software
refatorado ter as mesmas funes anteriores
(Fowler, 1999).
A refatorao ajuda no processo de identificao de bugs,

pois clarifica a estrutura do programa e torna mais fcil a
localizao de problemas. Refatorao ajuda a programar
de forma mais rpida, apesar de isso parecer estranho.
Melhorar o projeto e legibilidade no reduz a velocidade do
desenvolvimento? Em longo prazo, esses fatores vo tornar
mais fceis as adies de novas funcionalidades e correes
de bugs, que sero feitas de forma mais rpida. A
refatorao no uma atividade que deve ser agendada.
Ela deve ser feita continuamente, em pequenos passos.

Um momento oportuno para refatorar quando uma

nova funcionalidade deve ser adicionada. A
refatorao nesse caso pode ajudar a tornar o cdigo
mais fcil de entender imediatamente. Melhorando o
projeto, a nova funcionalidade pode ser adicionada de
forma mais simples e rpida, sem introduzir novos
bugs. A refatorao vai ajudar a encontrar bugs mais
facilmente, porque o cdigo se torna mais legvel,
mais claro.
Outro bom momento para refatorar quando so

feitas revises no cdigo. Grandes organizaes
realizam constantes revises no cdigo a fim de
garantir a qualidade. Isso tambm ajuda a
desenvolvedores mais experientes a transmitirem seu
conhecimento aos menos experientes. Ajudam a
sugerir ideias. As refatoraes nesse caso so uma
forma mais concreta de se obter resultados de uma
reviso de cdigo.
Gerentes e Refatoraes
Programas possuem dois tipos de valores: o que eles

podem fazer hoje e o que eles podem fazer amanh.
Na maior parte do tempo, a programao foca no que
o programa deve (ou pelo menos deveria) fazer hoje.
A refatorao uma forma de ligar o hoje com o
amanh. Quando uma deciso no faz sentido hoje,
muda-se a deciso, ento o trabalho pode ser feito.

O que fazem os programas difceis de serem trabalhados:

Programas difceis de ler so difceis de modificar;
Programas que tm a lgica duplicada so difceis de
modificar;
Programas que requerem comportamento adicional que
precisam modificar seu cdigo de execuo so difceis
de alterar;
Programas com lgica complexa so difceis de
modificar.

Ento, programas devem ser fceis de ler, devem ter a

lgica especificada em apenas um nico lugar, que
permitam ser modificadas sem alterar o
comportamento externo observvel, e que permita
que lgicas condicionais possam ser expressas de
forma simples.

Se refatoraes so importantes, porm no

modificam o comportamento externo observvel,
como explicar a sua necessidade para gerentes, que
normalmente no tm experincia tcnica? Qualidade
um aspecto chave, este termo pode convencer a
maioria dos gerentes do valor das revises do cdigo.

A refatorao tende a quebrar grandes problemas em problemas

menores (por exemplo, objetos). Porm, mais objetos precisam
ser gerenciados. E objetos nesse caso normalmente costumam
delegar tarefas a outros objetos, indiretamente. Por exemplo, ao
colocar a lgica de uma tarefa em um mtodo chamado por
vrios objetos, utiliza-se uma boa prtica de compartilhamento.
Alm disso, a inteno do mtodo e sua implementao so
feitas separadamente. Com isso, isola-se algo que pode mudar,
evitando replicao ao mesmo tempo em que deixa o cdigo
limpo. Tudo isso, no entanto, no ir modificar o comportamento
externo, porm o programa ter mais valor, pois tem qualidades
que sero mais apreciadas amanh.

Problemas das Refatoraes
A refatorao, no entanto, tambm tem seus

problemas. Muitas aplicaes de banco de dados so
fortemente acopladas com esquemas de banco de
dados. Uma soluo considerar a utilizao de uma
camada intermediria de comunicao com o banco
de dados, que isole muitas das responsabilidades,
permitindo flexibilidade. Outro problema diz respeito
modificao de interfaces de objetos.

Bons projetistas modelam classes (interfaces) e relaes, de

forma que uma modificao possa ser feita internamente na
implementao sem modificar suas interfaces pblicas. Porm,
muitas refatoraes modificam essas interfaces, por exemplo, a
Renomear Mtodo (Rename Method). Isso desencadear uma
srie de modificaes em todos os locais onde o mtodo
invocado. Uma boa soluo manter uma verso de transio,
fazendo que a interface antiga ainda possa ser usada at que a
nova a substitua completamente. Uma boa dica nunca publicar
interfaces prematuramente, pois interfaces, segundo os
fundamentos da programao orientada a objetos, devem (ou
deveriam) ser imutveis.

E quando no se deve refatorar? A refatorao, por

definio, no muda o comportamento observvel.
No deve ser usada em princpio para corrigir bugs,
mas como uma forma de ajudar a identific-los. Se um
sistema de software est repleto de bugs e est difcil
de estabiliz-lo, talvez uma melhor opo seria
reescrev-lo do zero, o que no uma deciso fcil.

Refatorao e Projeto
A refatorao serve como uma alternativa ao chamado big

design up-front (Grande Projeto Antecipado, ou G.P.A.).
Nesse cenrio no se cria inicialmente um grande projeto,
que tente prever todas as possibilidades de mudanas que
possam ocorrer no sistema de software. Ao invs disso,
criam-se pequenas pores do software bem desenhadas,
como sugere a XP (Extreme Programming). A refatorao
nesse caso d nfase nas mudanas. Utiliza-se a abordagem
up-front, porm no se tenta achar a soluo para tudo. Ao
desenvolver de forma evolutiva e incremental, o conceito
de soluo pode mudar, ou melhorar, e com a refatorao
isso no se torna um problema.

Refatorao e Performance
Ao tornar o sistema de software mais fcil de entender,

com mudanas no cdigo, frequentemente far o mesmo
rodar mais lento. No entanto, um cdigo mais limpo
facilitar os testes de performance (tuning). A maioria dos
problemas de performance em sistemas de software se
concentra em pequenas pores isoladas do cdigo. A
preocupao com performance pode se dar apenas no final
de um projeto, o qual deve ser desenvolvido com constante
refatorao. Existe uma fase de otimizao especfica para
este fim.

1 - Composing Methods
Extract Method
Inline Method
Inline Temp
Replace Temp with Query
Introduce Explaining Variable
Split Temporary Variable
Remove Assignments to Parameters
Replace Method with Method Object
Substitute Algorithm

2 - Moving Features between Objects
Move Method
Move Field
Extract Class
Inline Class
Hide Delegate
Remove Middle Man
Introduce Foreign Method
Introduce Local Extension

3 Organizing Data
Self Encapsulate Field

Replace Data Value with Object Encapsulate Field
Change Value to Reference Encapsulate Collection
Change Reference to Value Replace Record with Data
Replace Array with Object Class
Duplicate Observed Data Replace Type Code with Class
Change Unidirectional Association Replace Type Code with
to Bidirectional Subclasses
Change Bidirectional Association Replace Type Code with
to Unidirectional State/Strategy
Replace Magic Number with Replace Subclass with Fields
Symbolic Constant
4 Simplifying Conditional
Expressions
Decompose Conditional
Consolidate Conditional Expression
Consolidate Duplicate Conditional Fragments
Remove Control Flag
Replace Nested Conditional with Guard Clauses
Replace Conditional with Polymorphism
Introduce Assertion

5 Making Methods Calls Simpler
Rename Method
Introduce Parameter Object
Add Parameter
Remove Setting Method
Remove Parameter
Hide Method
Separate Query from Modifier
Replace Constructor with
Parameterize Method
Factory Method
Replace Parameter with Explicit
Encapsulate Downcast
Methods
Replace Error Code with
Preserve Whole Object
Exception
Replace Parameter with Method
Replace Exception with Test

6 Dealing with Generalization
Pull Up Field Extract Superclass

Pull Up Method Extract Interface
Pull Up Constructor Body Collapse Hierarchy
Push Down Method Form Template Method
Push Down Field Replace Inheritance with
Extract Subclass Delegation
Replace Delegation with
Inheritance
Concluso
Padres de Projeto so solues reutilizveis para problemas

recorrentes no desenvolvimento orientado a objetos. No entanto,
aplicar padres antecipadamente em um projeto requer mais tempo e
aumenta custos, ao mesmo tempo em que aumenta sua complexidade.
Requisitos so modificados, criados ou mesmo eliminados conforme
projetos evoluem. Tentar aplicar padres antecipadamente para prever
essas mudanas um problema conhecido como excesso de
engenharia. J projeto em escassez reduz custos, pois o sistema de
software criado rapidamente devido falta de tempo, conhecimento
ou necessidade de se adicionar funcionalidades em curto prazo. Ao
longo do tempo, armazena-se um dbito de projeto, que torna o
sistema de software muito difcil de ser mantido e evoludo. nesse
contexto que entram as refatoraes, como uma forma de melhorar o
projeto existente sem alterar seu comportamento externo observvel.
Refatorao o aspecto-chave para um projeto evolutivo, e na
evoluo que se encontra a verdadeira sabedoria.

Referncias Bibliogrficas
FOWLER, M. Refactoring: Improving the Design of Existing

Code. Addison-Wesley, 1999. Object Technologies Series.
KERIEVSKY, J. Refatorao para Padres. Bookman, 2008.
GAMMA, E.; HELM, R.; JOHSON, R.; VLISSIDES, JOHN. Padres
de Projeto: Solues reutilizveis de software orientado a
objetos. Addison-Wesley, 1995).
BECK, K. Extreme Programming Explained: Embrace Change.
Boston, USA:
Addison-Wesley, 1999.
BECK. K. Test-Driven Development. Boston, MA: Addison-
Wesley, 2002.

Obrigado! Dvidas? Contato:
http://www.facebook.com/guintherpauli
http://www.twitter.com/guintherpauli
http://br.linkedin.com/in/guintherpauli
http://www.gpauli.com
guintherpauli@gmail.com
gpauli@gpauli.com
guinther.pauli
guintherpauli@gmail.com

Refatoração POO PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Refatoração POO PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Programao Orientada a Objetos

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 3

Bad Smells (Code Smells)

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 4

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 5

De acordo com Kent Beck, bad smells (maus

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 6

Rigidez uma alterao em um ponto do cdigo requer

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 7

Este provavelmente um dos problemas mais graves

Consiste de um mtodo com uma implementao de lgica

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 9

Uma boa prtica da programao orientada a objetos

Um mtodo que recebe muitos parmetros sugere que classes

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 11

Ocorre quando uma classe alterada geralmente de

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 12

Esta situao o oposto de Mudana Divergente

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 13

Ocorre quando um mtodo realiza a maioria das suas

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 14

Ocorre normalmente quando dados costumam

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 15

Existem basicamente dois tipos de dados na maioria das

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 16

Testar vrias possibilidades com sentenas switch

Nesse caso, cada vez que uma classe se torna

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 18

Cada classe criada no sistema de software tem um

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 19

Este problema ocorre quando se projeta uma soluo

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 20

Muitas vezes um objeto tem sua varivel de instncia

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 21

Ocorre quando um cliente consulta um objeto a partir

O encapsulamento um dos principais recursos da

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 23

Muitas vezes classes se tornam demasiadamente

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 24

Ocorre com mtodos que fazem a mesma coisa, mas

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 25

Objetos so o princpio bsico da reutilizao de

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 26

Classes de dados normalmente contm muitos

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 27

Classes herdam mtodos e dados de classes

Comentrios so bons, porm, um cdigo com muitos

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 29

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 30

O que um cdigo limpo:

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 31

Nomes significativos, que revelam sua inteno;

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 32

Mtodos pequenos (5 ou 10 linhas);

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 33

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 34

Chrisptopher Alexander, um arquiteto, professor e

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 35

Padres ajudam a solucionar problemas de projeto, por

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 37

As solicitaes so a nica maneira de conseguir que um

Padres de Projeto e Refatorao - Guinther Pauli www.gpauli.com 38

A parte difcil sobre projeto orientado a objetos a