A grande virtude dos padres de software que eles carregam muitas idias

teis de projeto. Conseqentemente, se voc aprender um punhado destes

padres deveria ser um projetista de software muito bom. Certo? Eu me con-
siderava muito bom uma vez que tinha aprendido e utilizava algumas dzias
de padres. Eles me auxiliaram a desenvolver frameworks mais flexveis e a
construir sistemas de software robustos e extensveis. Aps alguns anos, en-
tretanto, descobri que meu conhecimento de padres e a maneira como eu os
utilizava levava-me muitas vezes a projetar meu trabalho em excesso.
Uma vez que minhas habilidades em projeto haviam melhorado, en-
contrei-me utilizando padres de uma maneira diferente. Eu iniciava a re-
fatorar para, rumo a e contrrio a padres, ao invs de utiliz-los em um
projeto antecipado ou introduzindo-os muito cedo em meu cdigo. Minha
nova maneira de trabalhar com padres surgiu da minha adoo de prticas
de projeto de programao extrema (XP), as quais me auxiliaram a evitar
projetar tanto em excesso quanto em escassez.
Excesso de engenharia
Quando voc torna seu cdigo mais flexvel ou sofisticado do que ele ne-
cessita ser, est projetando em demasia. Alguns programadores fazem isso
porque acreditam que conhecem os futuros requisitos do sistema. Eles argu-
mentam que melhor fazer um projeto mais flexvel ou sofisticado hoje, de
forma que ele possa acomodar as necessidades de amanh. Isto soa razovel
se voc for um vidente.
Se suas previses estiverem erradas, voc perde tempo e dinheiro pre-
ciosos. No incomum gastar dias ou semanas ajustando e otimizando um
Captulo 1
Por Que Escrevi Este Livro
Refatorao para Padres 26
projeto de software demasiadamente flexvel ou desnecessariamente sofisti-
cado, deixando-o com menos tempo para adicionar novos comportamentos
ou remover defeitos.
O que normalmente acontece com cdigo que voc produz ao ante-
cipar necessidades que nunca se materializam? Ele nunca removido. Isto
acontece porque ou inconveniente remover o cdigo ou porque voc es-
pera que um dia aquele cdigo possa ser necessrio. Independentemente da
razo, medida que cdigo demasiadamente flexvel ou desnecessariamente
sofisticado vai se acumulando, voc e o resto dos programadores de sua
equipe, especialmente os novos, devem operar em uma base de cdigo que
maior e mais complicada do que precisaria ser.
Para compensar, as pessoas decidem trabalhar em reas disjuntas de um
sistema. Isso parece tornar o trabalho delas mais simples, entretanto tem o
desagradvel efeito colateral de gerar diversas duplicaes de cdigo porque
cada um trabalha em sua zona de conforto do sistema, raramente buscando
em algum outro lugar por cdigo que j faz aquilo que ele ou ela precisa.
Cdigo projetado em demasia afeta a produtividade porque quando os
programadores herdam tal projeto, eles devem gastar tempo aprendendo as
nuances daquele projeto antes que possam estender ou manter este projeto
confortavelmente.
Projeto em excesso tende a ocorrer silenciosamente; muitos arquitetos
e programadores nem esto cientes do que esto fazendo. E embora suas
organizaes possam notar um declnio na produtividade da equipe, poucos
sabem que o projeto em excesso tem um papel neste problema.
Talvez a principal razo pela qual os programadores projetam em ex-
cesso que eles no querem ficar presos a um projeto ruim. Um projeto
ruim pode entrelaar-se de maneira to profunda no cdigo que melhor-lo
torna-se um desafio enorme. Presenciei situaes deste tipo e por isto que
projeto antecipado com padres era to atrativo para mim.
A panacia dos padres
Quando comecei a aprender sobre padres, eles representavam uma manei-
ra flexvel, sofisticada e at mesmo elegante de projetar software orientado a
objetos, que eu queria muito dominar. Aps estudar cuidadosamente diver-
sos padres e linguagens de padres, utilizei-os para melhorar os sistemas
que eu j havia construdo e para formular projetos para os sistemas que iria
construir. Dado que os resultados destes esforos eram promissores, tive a
certeza de que estava no caminho certo.
Entretanto, ao longo do tempo, o poder dos padres conduziu-me a
perder a viso de como escrever cdigo de forma mais simples. Aps apren-
Captulo 1 Por Que Escrevi Este Livro 27
der que existem duas ou trs maneiras diferentes de realizar uma computa-
o, eu imediatamente corria rumo a implementao do padro Strategy,
quando, na verdade, uma simples expresso condicional teria sido mais fcil
e mais rpida de programar uma soluo perfeitamente suficiente.
Em uma ocasio, minha preocupao com padres tornou-se evidente.
Estava programando em par, e meu colega e eu havamos escrito uma classe
que implementava a interface TreeModel de Java de forma a mostrar um grafo
de objetos do tipo Spec em um widget em forma de rvore. Nosso cdigo
funcionou, entretanto o widget estava mostrando cada objeto Spec atravs da
chamada ao seu mtodo toString(), o qual no retornava a especificao de
Spec que gostaramos. Ns no podamos mudar o mtodo toString() de Spec
porque outras partes do sistema dependiam de seu contedo. Ento pensa-
mos em como proceder. Como era meu hbito, considerei quais padres po-
deriam auxiliar. O padro Decorator veio minha mente, e sugeri que fosse
utilizado para envolver Spec com um objeto que pudesse sobrescrever o m-
todo toString(). A resposta de meu colega para minha sugesto surpreendeu-
me. Utilizar um Decorator aqui seria como usar uma marreta para um pro-
blema em que apenas algumas marteladas com um pequeno martelo seriam
suficientes. Sua soluo foi criar uma pequena classe chamada NodeDisplay,
cujo construtor pegava uma instncia de Spec e cujo nico mtodo pblico
toString() obtinha a informao correta a ser mostrada a partir da instncia
de Spec. NodeDisplay levou pouco tempo para ser programada, pois possua
menos de 10 linhas de cdigo simples. Minha soluo usando um Decorator,
envolveria a criao de cerca de 50 linhas de cdigo, com muitas chamadas
repetitivas que delegariam o controle para a instncia de Spec.
Experincias como esta me tornaram ciente de que precisaria parar
de pensar tanto em padres e mudar o foco para escrever cdigo pequeno,
simples e fcil de entender. Eu estava em uma encruzilhada: trabalhei duro
para aprender padres para tornar-me um melhor projetista de software,
entretanto agora precisava relaxar minha confiana neles de forma a poder
tornar-me verdadeiramente melhor.
Escassez de engenharia
Projeto em escassez muito mais comum que projeto em excesso. Ns pro-
jetamos em escassez quando produzimos software mal projetado. Isso pode
ocorrer por diversas razes:
No temos tempo, no fazemos tempo ou no nos dado tempo
suficiente para refatorar.
No temos conhecimento acerca de bom projeto de software.
Refatorao para Padres 28
Esperam que sejamos capazes de adicionar rapidamente novas fun-
cionalidades a sistemas existentes.
Fazem-nos trabalhar em muitos projetos paralelamente.
Ao longo do tempo, software projetado em escassez torna-se caro, di-
fcil de manter ou uma baguna que no possvel ser mantida. Brian Foote
e Joseph Yoder, que so autores de uma linguagem de padres chamada de
Big Ball of Mud, descrevem tal software como:
Estruturas de dados podem ser construdas de maneira aleatria, ou
prximas da inexistncia. Todos conversam com todos. Cada pequeno
pedao de informao sobre estado pode ser global. Onde a informao
de estado compartimentalizada, esta pode ser passada promiscuamente
atravs de canais bizantinos que evitam a estrutura original do sistema.
Nomes de variveis e funes podem ser no-informativos, ou at
mesmo enganadores. Funes podem fazer uso intensivo de variveis glo-
bais, assim como de longas listas de parmetros mal definidos. As fun-
es so longas e intricadas e realizam diversas tarefas no-relacionadas.
Cdigo duplicado. O fluxo de controle difcil de entender e difcil de
seguir. A inteno do programador prxima do impossvel de ser reco-
nhecida. O cdigo simplesmente ilegvel e as fronteiras indecifrveis. O
cdigo exibe os sinais aparentes de que remendos em cima de remendos
foram sendo feitos por mltiplos mantenedores, cada um dos quais mal
entendia as conseqncias do que estava fazendo. [Foote e Yoder, 661]
Embora os sistemas que voc tem trabalhado possam no ser to horr-
veis assim, provvel que tenha feito algum projeto em escassez. Eu sei que
fiz. Existe simplesmente uma fora irresistvel de ter um cdigo funcionando
rapidamente, que normalmente vem acompanhada de foras poderosas que
impedem nossa necessidade de melhorar o projeto de cdigo existente. Em
alguns casos, ns conscientemente no melhoramos o cdigo porque sabe-
mos (ou pensamos que sabemos) que ele no ter uma vida longa. Outras
vezes, somos compelidos a no aperfeioar nosso cdigo porque gerentes
bem-entendidos explicam que nossa organizao ser mais competitiva e
bem-sucedida se ns no consertarmos o que no est quebrado.
Projeto em escassez de forma contnua leva ao ritmo de desenvolvimen-
to de software rpido, lento, mais lento, que segue mais ou menos como:
1. Voc rapidamente entrega a verso 1.0 do sistema com cdigo
ruim.
2. Voc entrega a verso 2.0 do sistema, e o cdigo ruim retarda o
desenvolvimento.
Captulo 1 Por Que Escrevi Este Livro 29
3. medida que voc tenta entregar verses futuras, vai cada vez mais
devagar enquanto o cdigo ruim se multiplica, at que as pessoas
comeam a perder a f no sistema, nos programadores e at mesmo
no processo que levou todo mundo a esta posio.
4. Em algum ponto durante ou depois da verso 4.0, voc percebe que
no pode ganhar, ento, comea a explorar a opo de uma reescri-
ta total.
Este tipo de experincia muito comum em nossa indstria de soft-
ware. custosa e torna as organizaes muito menos competitivas do que
elas poderiam ser. Felizmente, existe uma maneira melhor.
Desenvolvimento dirigido por testes e refatorao contnua
O desenvolvimento dirigido por testes [Beck, TDD] e refatorao contnua,
duas das muitas prticas excelentes de XP, tm melhorado dramaticamente
a maneira pela qual construo software. Descobri que estas duas prticas
tm ajudado a mim e s organizaes para as quais trabalhei a gastar menos
tempo projetando em excesso ou em escassez e mais tempo criando cdigo
rico em funcionalidades, de alta qualidade e produzidos no prazo.
O desenvolvimento dirigido por testes (TDD) e refatorao contnua
possibilitam a evoluo eficiente de cdigo funcional ao tornar a programa-
o um dilogo.
Pergunta: Voc faz uma pergunta ao sistema escrevendo um teste.
Resposta: Voc responde a pergunta escrevendo cdigo que passa
no teste.
Refinamento: Voc refina a pergunta consolidando idias, removen-
do coisas desnecessrias e clarificando ambigidades.
Repetio: Voc mantm o dilogo fazendo novas perguntas.
Este ritmo de programao colocou a minha cabea em um lugar com-
pletamente diferente. Ao usar TDD, ao invs de gastar um monte de tempo
pensando sobre um projeto que poderia funcionar para cada nuance de um
sistema, gasto agora segundos ou minutos criando um pedao primitivo do
comportamento que funcione corretamente antes de refatorar e evoluir este
cdigo para o prximo nvel necessrio de sofisticao.
O mantra de Kent Beck em TDD e refatorao contnua vermelho,
verde, refatorar. As cores referem-se ao que voc v quando escreve cdigo
Refatorao para Padres 30
e roda um teste em uma ferramenta de testes unitrios (como o JUnit). O
processo segue como a seguir.
1. Vermelho: Voc cria um teste que expressa o que espera que o cdi-
go faa. O teste falha (fica vermelho) porque voc ainda no criou
cdigo para fazer com que ele passe.
2. Verde: Voc programa o que necessrio para fazer com que o teste
passe (fique verde). No fica se punindo para criar um projeto livre
de duplicaes, simples ou claro neste ponto. Voc ir rumo a este
projeto mais tarde, quando seu teste estiver passando e puder expe-
rimentar confortavelmente projetos melhores.
3. Refatorar: Voc melhora o projeto do cdigo que passou no teste.
Embora possa parecer simples, TDD e refatorao contnua viraram o
mundo da programao de cabea para baixo. O programador inexperiente
pode pensar, Escrever um teste para um cdigo que no existe? Escrever
cdigo que passe no teste e que ainda assim precise de refatorao imediata-
mente? Isto uma abordagem para desenvolvimento de software voltada ao
desperdcio e sem cuidado algum ou o qu?.
Na verdade, justamente o contrrio. TDD e refatorao contnua for-
necem um estilo de programao leve, iterativo e disciplinado que maximiza
o foco, diminuindo o estresse mantendo a produtividade. Desapressada-
mente Rpido como Martin Fowler descreve esse estilo [como citado por
Beck, TDD], enquanto Ward Cunningham explica que TDD e refatorao
contnua tratam mais sobre anlise e projeto contnuos do que sobre testes.
Aprender o ritmo certo de TDD e refatorao contnua requer prti-
ca. Tony Mobley, um programador que conheo, descreveu esse estilo de
desenvolvimento como uma mudana de paradigma to grande, se no for
maior, que aquela para mover de programao estruturada para programa-
o orientada a objetos. Entretanto, leva tempo para que voc se acostume
com esse estilo de desenvolvimento. Uma vez que se acostume, descobrir
que desenvolver cdigo de produo de qualquer outra forma soa estranho,
desconfortvel, at mesmo no-profissional. Muitos de ns que programam
usando TDD e refatorao contnua descobrimos que estas prticas nos aju-
dam a:
Manter baixa a contagem de defeitos
Refatorar sem medo
Produzir cdigo mais simples e melhor
Programar sem estresse
Captulo 1 Por Que Escrevi Este Livro 31
Para aprender as vantagens e desvantagens de TDD, estude Test-Dri-
ven Development [Beck, TDD] ou Test-Driven Development: A Practical
Guide [Astels]. Para experimentar como desenvolver usando TDD, veja
as sees de exemplo de Substituir rvore Implcita por Composite (210)
e Encapsular Composite com Builder (124). Para aprender como refatorar
continuamente, voc pode querer estudar Refatorao [F] (o primeiro cap-
tulo em particular) assim como as refatoraes deste livro.
Refatorao e padres
Em diversos projetos, observei o qu e como meus colegas e eu refatoramos.
Embora estivssemos usando muitas das refatoraes descritas em Refato-
rao [F], tambm encontramos lugares onde padres nos ajudavam a me-
lhorar nossos projetos. Nestes momentos, aplicvamos refatoraes para ou
rumo a padres, sendo cuidadosos para no produzir solues flexveis em
demasia ou desnecessariamente sofisticadas.
Quando explorei as motivaes para aplicar refatoraes direcionadas
a padres, descobri que elas so idnticas s motivaes gerais para imple-
mentar refatoraes de baixo nvel: para reduzir ou remover duplicao,
para simplificar o que est complicado e para tornar o cdigo melhor e
comunicar sua inteno.
Essa motivao pode ser facilmente perdida se voc estudar apenas uma
poro de um padro de projeto. Por exemplo, cada padro em Padres
de Projeto [DP] inclui uma seo conhecida como Inteno. Os autores de
Padres de Projeto descrevem a Inteno como segue: uma curta decla-
rao que responde s seguintes questes: O que faz o padro de projeto?
Quais os seus princpios e sua inteno? Que tpico ou problema particular
de projeto ele trata? [DP, 22]. Apesar desta descrio, as sees de Inteno
para muitos padres de projeto do apenas dicas do principal problema que
o padro resolve. Ao invs disso, muito do foco colocado no que o padro
faz. Aqui esto dois exemplos.
Inteno de Template Method
Definir o esqueleto de um algoritmo em uma operao, postergando al-
guns passos para as subclasses. Template Method permite que subclasses
redefinam certos passos de um algoritmo sem mudar a estrutura do mes-
mo [DP, 301].
Inteno de State
Permitir a um objeto alterar seu comportamento quando seu estado in-
terno muda. O objeto parecer ter mudado sua classe [DP, 284].
Refatorao para Padres 32
Estas descries de intenes no dizem que um Template Method aju-
da a reduzir ou remover cdigo duplicado em mtodos similares de sub-
classes em uma hierarquia ou que o padro State ajuda a simplificar lgicas
condicionais complexas que modificam o estado. Se os programadores es-
tudarem todas as sesses de um padro de projeto, em particular a seo
Aplicabilidade, eles aprendero sobre os problemas que o padro trata.
Entretanto, quando esto usando o livro Padres de Projeto durante
o projeto, muitos programadores, incluindo eu mesmo, j leram a seo
Inteno de um padro para ver se ele pode fornecer uma boa soluo para
uma dada situao. Este mtodo de escolher um padro no funciona to
bem quanto um mtodo que o ajude a casar um problema de projeto com
os problemas que o padro resolve. Por qu? Porque padres existem para
solucionar problemas, e aprender se eles realmente podem ajudar em uma
dada situao envolve entender quais problemas eles ajudam a resolver.
A literatura de refatorao tende a focar mais em problemas de projeto
especficos do que a literatura de padres. Se voc estudar a primeira pgina
de uma refatorao, ver qual o tipo de problema que a refatorao ajuda
a resolver. O catlogo de refatoraes dirigidas para padres apresentado
neste livro, que uma continuao direta do trabalho iniciado em Refatora-
o, pretende auxili-lo a ver que tipos de problemas especficos os padres
ajudam a resolver.
Embora este livro cubra o espao entre padres e refatorao, a cone-
xo entre os dois j havia sido notada pelos autores de Padres de Projeto
na concluso de seu excelente livro:
Nossos padres de projeto capturam muitas das estruturas que resultam
de refatorao
Padres de projeto ento fornecem alvos para suas refatoraes [DP,
326].
Martin Fowler faz uma observao similar no incio de Refatorao:
H uma relao natural entre padres e refatorao. Padres so onde
voc quer estar; refatoraes so modos de chegar l [F, 98].
Projeto evolutivo
Hoje, depois de estar bastante familiarizado com padres, as estruturas
que resultam de refatorao, sei que entender as boas razes que levam a
refatorar para ou rumo a um padro mais valioso que entender o resultado
final de um padro ou as nuances de implementar esse resultado final.
Captulo 1 Por Que Escrevi Este Livro 33
Se voc quer tornar-se um projetista de software melhor, estudar a evo-
luo de excelentes projetos de software ser mais valioso do que estudar
os excelentes projetos por si s. Porque na evoluo que se encontra a ver-
dadeira sabedoria. As estruturas que resultam da evoluo podem ajud-lo,
mas sem entender porque elas evoluram em um projeto, voc tem grandes
chances de no aplic-las corretamente ou de projetar em excesso em seu
prximo projeto.
At agora, nossa literatura em projeto de software tem focado mais em
ensinar boas solues do que ensinar evolues para boas solues. Precisa-
mos mudar isto. Como o grande poeta Goethe disse, O que os seus pais lhe
deixaram de herana, merea-o novamente se voc o possuir. A literatura
de refatorao est nos ajudando a readquirir um melhor entendimento de
boas solues de projeto revelando evolues perceptveis para estas solu-
es.
Se voc quer aproveitar padres ao mximo, deve fazer a mesma coisa:
veja padres no contexto de refatorao, no apenas como elementos reu-
tilizveis que existem separadamente das refatoraes. Esta minha razo
principal para produzir um catlogo de refatoraes direcionadas para pa-
dres.
Ao aprender a evoluir seus projetos, voc pode tornar-se um projetista
de software melhor e reduzir a quantidade de trabalho que projeta em ex-
cesso ou escassez. TDD e refatorao contnua so as prticas-chave para
projeto evolutivo. Introduza gradualmente refatoraes direcionadas para
padres no seu conhecimento de como refatorar e encontrar-se- mais bem
equipado para evoluir grandes projetos.