PadrCoes de projeto, aprecie

SECA BOAS PRATICAS: NESTA SECA VOCE ENCONTRA ARTIGOS SOBRE TECNICAS QUE PODERAO AUMENTAR A QUA1 PadrCoes de projeto, aprecie Principios para a utilizacäo adequada de Resumo DevMan De que se trata o artigo: 0 artigo trata de apresentar principios, discussoes e ref lexties sobre a utilizacao de padroes de projeto, para ajudar o leitor a desenvolver senso critico sobre os mesmos.assim, o leitor podera extrair de si mesmo o conhecimento para a aplicacao de padroes de projeto corn moderacào. Em que situadio o tema e tit& 0 terra é Otil por alertar o desenvolvedor sobre a utilizacao adequada de padroes de projeto, que sào solucties para determinados problemas, mas que tambe,m podem ser problemas para determinadas solu- Oes. importanteaodesenvolvedor saber julgar a utilizacao de urn padrao de projeto em urn determinado contexto, avaliando sua aplicabilidade e consequencias, buscando a solucao ideal., Padrties de projeto, aprecie com moderagio: Este artigo apresenta reflexi5es a respeito da utilizacao de padrties de projeto, e descrevealgumas causas comunsda ma utilizacao dos mesmos, alem de alguns exemplos de ma implementacao. Ern seguida, mostra os principios GRASP e sua relacao corn os padroes de projeto, para orientar o desenvolvedor a utiliza-los adequadamente. Ao final, disponibiliza perguntas para avaliar a implementacao de urn padrao de projeto e consideracoes para o leitor desenvolver seu senso critico. ao ha como negar a in fluencia deste termo na vida de quem N trabalha corn desenvolvimento de software. Seja por bem ou por mal, os padroes de projeto estdo presentes ha mais de uma decada, talvez desde que comecaram a possibilitar melhorias no desenvolvimento de software, ou entdo quando comecaram a serem vistos com bons olhos pelo mercado de trabalho. Todavia, tambem comecaram a causar deterioracäo de codigo e discordias, seja por mau uso, falta de entendimento a respeito ou falta de planejamento. Desta forma, passaram a ser criticados ao mesmo tempo em que elogiados. Tipicamente, padroes de projeto sao certamente beneficos, desde que implementados de maneira adequada e tendo em mente certos principios alguns dos quais serdo apresentados aqui. A intencdo deste artigo é esclarecer aos que lidam corn padroes de projeto, tanto os que forem a favor quanto os que forem contra, que padroes de projeto nab säo balas de prata. Eles podem ser solucaes para determinados problemas e problemas para determinadas solucoes. Por isso, é importante analisar cada situacdo corn senso critico. Portanto, serdo apresentados conceitos, principios e exemplos que the permitirao identificar situagoes parecidas em seu diaa-dia, alem de consideracoes gerais para aplicar seu senso critic() visando alcancar uma solucdo adequada. Em busca do codigo perfeito Ser urn experiente desenvolvedor de software ndo e um patamar que se alcanca de urn dia para o outro. Sao necessarios anos e anos de criteriosos estudos e vivencia profissional para se tornar digno de tal denomina0o. Para reduzir este hiato, muitos desenvolvedores procuram aprimorar-se nos atri- 54 Java Magazine Edich 98

DADE DO DESENVOLVIMENTO DE SOFTWARE com moderacäo adthes de projeto Aprimore seu senso critic a respeito da utilizacäo de padriies de projeto, confira situagies, reflexties e sua relacio com os principios GRASP TIAGO ROMERO GARCIA butos geralmente louvados que todo habilidoso desenvolvedor de softwares deva possuir. 0 que é de fato uma boa iniciativa, desde que se de minuciosa atencao a cada habilidade aprimorada. 0 problema acontece quando o desenvolvedor quer chegar neste nivel muito rapid, e acaba pecando no nivel de criteria afirmando saber algo que apenas tern uma nocao, e na hora da pratica acaba faltando o devido embasamento teorico. E exatamente o caso dos padroes de projeto. E muito facil alguern "achar que sabe bem" pad roes de projeto simplesmente por ter visto algumas implementacoes, ou por ter lido em alguma revista. claro que temos excecoes, mas geralmente e necessario urn pouco mais de vivencia para a real compreensao. E justamente pela tal falta de vivencia, criam-se situacoes onde pad roes de projeto nao sac, devidamente utilizados. Para exemplificar, confira algumas causas comuns da ma utilizacäo de padroes de projeto: Desatenccio a definiccio de padrdo 0 proposito real dos padroes de projeto é muitas vezes deixado de lado. Segundo Craig Larman, em seu livro Applying UML and Patterns (2005), urn padrao é urn par nomeado de problema/ solucäo que pode ser aplicado em urn determinado contexto, possuindo orientacao em como ser aplicado e discussao de suas consequencias. Desta forma, ao utilizar qualquer padrao, todo desenvolvedor deve atentar a duas premissas: Apenas implementar o padrao se sua aplicabilidade estiver de acordo corn o cenario; Apenas implementar o padrao se suas consequencias forem aceitaveis no cenario. Quem implementa padroes tern toda a responsabilidade pelo que esta introduzindo, entao o minim que se espera é que se busque justificar a introducao do padrao a partir das premissas aci ma. Vejamos urn exemplo favoravel a introducao de urn padrao de projeto: em urn sistema de e-commerce, é requisitado que o usuario possa escolher dentre diversos criterios para ordenar os resultados. Assim, um desenvolvedor considera o use do padrao de projeto GoF Strategy (Estrategia). Ao consultar a aplicabilidade de Strategy, ele percebe que sua ideia esta de acordo corn a proposta do padrao, visto que temos diversas variacoes de urn algoritmo, nao é desejavel expor os detalhes de cada algoritmo e a escol ha do criterio seria tipicamente codificada corn condicionais maltiplos. Agora, ao consultar as consequéncias de Strategy, ele verifica que criard uma familia de algoritmos relacionados, eliminard condicionais mtiltiplos e podera escolher urn criterio diferente a qualquer momento. Por outro lado, havera urn maior mlmero de objetos em memoria, o codigo cliente precisara estar pronto para receber diversos Strategies e havera urn overhead de comunicacao entre os Strategies e o contexto. Assim, apos verificar os impactos de tais consequencias perante os ganhos, considerando as particularidades do projeto em questao, o desenvolvedor conclui que e aconselhavel utilizar este padrao de projeto. Para ver urn exemplo desfavoravel, confira o topico Shortcut Factory a seguir, dentro da secao Exemplos de ma implementacao de padroes de projeto. Falta de simplicidade Uma das mais desrespeitadas premissas-chave no desenvolvimento de software é a de manter a simplicidade, ou seja, fazer apenas o necessario, adicionando o mini mo possivel de complexidade. Os autores do livro Head First Design Patterns (2004) explicam que os desenvolvedores da sua equipe sempre irao apreciar e admirar a simplicidade do seu codigo. Ha muitas vantagens nisso: o codigo fica menos susceptive! a erros, mais facia de compreender, havera menos documentacao, menos testes unitarios, etc. Tudo isso porque ha menos complexidade. Urn exemplo comum: certas vezes, alguns desenvolvedores nao consideram remover urn padrao de projeto que esta implementado, mesmo que ele esteja urn pouco fora de contexto ou introduzindo complexidade desnecessaria, apenas porque esta bonito no meio da arquitetura do software. Neste caso, e necessario deixar o apego ao codigo de!ado em favor de uma melhor efetividade geral. Cargo cult programming Outra causa nao incomum da ma utilizacao de padroes de projeto e conhecida por "cargo cult programming", que significa "programacao do culto a carga". Segundo a Wikipedia, "culto a carga e urn grupo de movimentos religiosos que aparece em sociedades tribais. (...) Surge corn o fato de os nativos observarem grupos industrializados recebendo material por encomendas (cargas), geralmente grupos militares recebendo suprimentos por barcos e avioes. Os nativos acabam nao compreendendo a origem destas cargas e atribuindo isto a Edich 98 Java Magazine 55

PadrOes de projeto, aprecie com moderacio causas sobrenaturais. Muitas vezes, grupos ritualisticamente imitam a forma de andar e se vestir dos grupos industrializados na esperanca de receber tambem a "carga" destas entidades sobrenaturais.". De semel ha nte maneira, alguns programadores cultuam o ritual de incluir codigos que nao tern proposito algum, acreditando que alcancarao sucesso por causas sobrenaturais. Geralmente, o programador esta trabalhando em um defeito, o qual nao esta entendendo, e por pressao e desespero joga urn codigo que nao compreende, mas que milagrosamente fez o defeito sum ir (ou pior, permanecer, mas ficar maquiado). Urn exemplo de tal ritual é a inclusao de um padrao de projeto ern urn cenario totalmente desnecessario. Assim, obtem um codigo elegante que agradard o lider tecnico, que adora ver seus desenvolvedores acrescentando padroes de projeto. 0 que se torna LI ma ilusao generalizada.?senvolvedor sedento por padroes e ainda por cima vidente Alguns desenvolvedores que acabaram de aprender sobre padroes de projeto e estâo sedentos para implements-los possuem um comportamento negativo: projetar mentalmente a implementacao de padroes de projeto em qualquer brecha que vier em seus p rojetos, independentemente se isso vai ou nao ao encontro dos requisitos de negocio ou as especificacoes tecnicas. Assim, ao observar urn cenario, um desenvolvedor ja imagina ma situacao onde no futuro podera existir algum outro requisito, ou ate mesmo a evolucáo de um requisito atual que demonstrard a necessidade de utilizacao de princfpios como polimorfismo e indirecâo. Sem consultar ninguern, ele ja sai desenvolvendo urn cenario complexo, susceptive] a erros, diffcil de ser testado e, alem de tudo, corn uma grande possibilidade de nunca ser utilizado. Assim sendo, sua decisao acaba impactando em atraso e no custo do projeto, visto que vai requerer mais horas de testes, mais documentacao e ainda e possfvel que tenha introduzido algum defeito ou brecha no codigo. Nor ainda e o cenario onde o desenvolvedor arquiteta o use de d [versos padroes de projeto ao mesmo tempo, mais por satisfacâo pessoal que por necessidade, simplesmente para dizer que implementou tal padrao antes", criando assim camadas e camadas de indirecao e comprometendo a performance e legibilidade. Os autores do livro Head First Design Patterns (2004) deixam bem claro: voce nao deve pensar que nao é urn desenvolvedor sofisticado se nao utilizar urn padrao para solucionar urn problema. Exemplos de ma implements* de padriies de projeto A implementacao fracassada de padroes de projeto acontece mu i- tos vezes por causas como as citadas anteriormente. Sao deixadas de lado importantes consideracoes e princfpios, e sao adotados raciocfnios passfveis de fracassos, que apresentam despreparo em avaliacâo de impacto. Para exempl ificar o que estamos discutindo, neste topico yams analisar tres situagoes de ma implementacao de padroes de projeto. Indireccio desnecessaria Ind i recâo e urn princfpio comum em padroes de projeto, que acontece quando o resultado de uma responsabilidade e transferido para outra classe, geralmente como delegacao ou heranca. Este princfpio e melhor detalhado posteriormente neste artigo, na secdo Princfpios GRASP. Agora, muita indirecao pode ser urn exemplo de ma implementacao, pois a responsabilidade e transferida excessivamente, criando complexidade e aumentando o tamanho da pilha de execucao. E certo que certas vezes isto é algo inevitavel, mas deve ser evitado sempre que possfvel. Note a delegacao excessiva nas Listagens 1, 2, 3 e 4, envolvendo os padrbes de projeto J2EE Business Object (Objeto de NegOcio), Business Delegate (Delegacao de NegOcio) e o padrao de projeto GoF Facade (Fachada). Este exemplo ilustra a construcao de estatisticas de venda para obter-se a receita diaria, em um cenario tfpico de uma aplicacao Java EE, onde Business Objects representam a responsabilidade pela logica de negocio, Business Delegate representam a delegacao de pa rtes da logica de neg6cio a objetos mais especificos, e Facade responde por um subsistema encapsulado. Para reflexao: Como voce melhoraria este cenario se the fosse solicitado? Considere que o seu anal ista de sistemas decidiu que necessario reduzir a complexidade e a pilha de execucao o maxim possfvel dentro de cada pacote Java. Singletonite, ou "singletonitis" Singletonite e uma "doenca" que faz voce utilizar muitas vezes o pad rão de projeto GoF Singleton, mesmo quando nä é necessario. E definida por Antonio Vieiro em seu artigo "Singletonitis". Sua causa e comum, visto que é urn padrao de projeto largamente utilizado e difundido, e sendo assi m Mc) conhecido, torna-se urn alvo facil para interpretacoes erroneas. A segui r, eis algumas das pri ncipa is consequencias: Singletons podem nao ser tinicos: ha frameworks que implementam o conceito de Singleton, como o Spring, onde pode-se determinar que uma certa classe sera instanciada como urn Singleton, e o framework ficara responsavel por isto. No entanto, ao implementar urn Singleton em codigo Java puro, utiliza-se static para armazenar a instancia na classe. Assim, tern-se que tal Singleton é 6 nico por classloader. No entanto, aplicacoes Java EE podem utilizar mais de urn classloader, e desta maneira pode haver mais de uma instancia deste Singleton; Singletons nao foram projetados para multithreading: a pretensào do Singleton de ser tinico na aplicacao faz corn que certos problemas fiquem mais complexos, por tornar mais diffcil o compartilhamento de recursos entre threads. Por exemplo: como compartilhar adequadamente uma instancia de urn Singleton entre diversas threads, de maneira sincrona? 0 problema esta quando voce desenvolve considerando uma instancia Unica, usando urn Singleton, e repentinamente descobre que esta instancia Unica esta presente em diversas threads; Singletons podem proporcionar alto acoplamento: Singletons podem promover acoplamento entre pa rtes de uma aplicacdo 56 Java Magazine Edicâo 98

que nao deveriam ser acopladas. Por exemplo, imagine que ha urn Singleton sendo acessado tanto pela camada de apresentacáo quanto pela camada de negocio. Considere agora que foi decidido replicar a camada de negocio em 10 servidores de aplicac5o e a camada de apresentacäo em 2 servidores web. A situacäo fica complicada porque o mesmo Singleton esta acoplado em a mbas as camadas, criando urn di ficil problema de compartilhamento de urn recurso em diversos servidores; Singletons atrapalham testes unitarios: o objetivo de fazer testes unitarios e o de testar cada classe independentemente, mas se a classe fizer use de urn Singleton, sera necessario testar Singleton junto, pois ha urn acoplamento entre a classe e o mesmo; Singletons sdo imutiveis: Singletons nä sac) polimorficos. Portanto, qualquer mudanca devera ser feita em termos de codigo. Se em tempo de producâo for necessario adicionar urn parametro a urn metodo do Singleton, nä sera possivel utilizar uma estrategia em tempo de execucao como a insercao de uma classe que estende o Singleton corn a desejada alteracäo. Para reflex5o: Voce consegue identificar algum sintoma de Singleton ite em algum Singleton que voce tenha implementado? Em caso positivo, é possivel planejar uma "cura"? Considere cada uma das consequencias apresentadas acima corn respeito ao seu Singleton. Ao identificar urn sintoma, trabalhe na origem do problema, e nao em seu resultado. Em algumas situaccies, pode ser melhor remover o Singleton do sistema ao inves de remedia-lo. Shortcut Factory Outro exemplo recorrente pode ser chamado de Shortcut Factory (Fabrica-atalho). Neste caso, o padfao de projeto GoF Factory (Fabrica) é usado simplesmente para servir como atalho para a instanciacâo de urn objeto, que seria feita em uma longa linha de codigo. A justificativa para isto e puro capricho do desenvolvedor e nada mais que isso. De acordo corn o GoF, no livro Design Patterns (1994), Factory é aplicavel quando: Uma classe nao sabe de antemao qual é. a classe dos objetos que devem ser criados por ela; Uma classe deseja que suas subclasses decidam qual é a classe dos objetos que devem ser criados por ela; Uma classe delega responsabilidades a uma de varias subclasses auxiliadoras, e voce deseja saber qual é a subclasse auxiliadora delegada. Estas sâo as justificativas de aplicabilidade de Factory. Portanto, se voce criou urn metodo para facilitar a instanciacâo de objetos conhecidos, voce nä implementou Factory. Veja o exemplo da Listagem 5. Para reflexdo: Quais alteracoes poderiam justificar a aplicacao de Factory? Considere motivos condizentes corn a aplicabilidade de Factory neste cenario. Como devem ser os requisitos para que a implementacao seja valida? Listagem 1. C6digo da classe EstatisticasManager. package br.com.javamagazine.estatisticas; import java.util.date; import br.com.javamagazine.vendas.vendasbusinessobject; public class EstatisticasManager private VendasBusinessObject salesbusinessobject; public void construirestatisticasdiarias() ( //... String receitadiaria = salesbusinessobject.obterreceitadiaria(new Date()); //... Listagem 2. COdigo da classe VendasBusinessObject. package br.com.javamagazine.vendas; import java.util.date; public class VendasBusinessObject private VendasBusinessDelegate vendasbusinessdelegate; public String obterreceitadiaria(date date) { return vendasbusinessdelegate.obterreceitadiaria(date); } // Mais metodos... Listagem 3. COdigo da classe VendasBusinessDelegate. package br.com.javamagazine.vendas; import java.util.date; import br.com.javamagazine.relatorios.relatoriosfacade; public class VendasBusinessDelegate { private RelatoriosFacade relatoriosfacade; public String obterreceitadiaria(date date) { return relatoriosfacade.obterreceitadiaria(date); } // Mais metodos... Listagem 4. COdigo da classe RelatoriosFacade. package br.com.javamagazine.relatorios; import java.util.date; public class RelatoriosFacade public String obterreceitadiaria(date date) { String receitadiaria = null; ReceitaReport receitareport = new ReceitaReport(); receitareport.setdate(date); // receitadiaria = logica de ReceitaReport return receitadiaria; // Mais metodos... Listagem 5. COdigo da classe SuprimentosFactory. package br.com.javamagazine.suprimentos; public class SuprimentosFactory ( public Caneta criarcanetapreta() return new Caneta("preta"); public Regua criarreguade30cm0 return new Regua(30, Unidades.CM); Edich 98 Java Magazine 57

PadrOes de projeto, aprecie com moderacio Principios GRASP Segundo Craig Larman, em seu livro Applying UML and Patterns (2005), GRASP sac) padroes que descrevem princlpios fundamentais ao projetar objetos e atribuir responsabilidades. 0 GRASP possui dois significados: e o acronimo de General Responsibility Assignment Software Patterns (Padraes Gerais de Atribuicao de Responsabilidades em Software), e tambem urn verbo no Inglés, to grasp, que significa alcancar corn a mente, compreender. Conhecer estes padroes esta diretamente relacionado corn o born use dos padroes de projeto, pois os padroes GRASP sao baseados em principios da Orientacao a Objetos que devem sempre ser seguidos, e que certamente foram utilizados na concepcao dos padroes de projeto. - E aconselhcivel que os desenvolvedores tenham sempre os padröes GRASP em mente no momento em que estiverem avaliando uma possivel implementao o de urn padrâo de projeto. Deste modo, visando facilitar a compreensao dos padroes GRASP, sao apresentadas a seguir algumas reflexoes sobre cada padrao e sua releitura corn relacao aos padroes de projeto. Especialista da Informagio Este principio esta relacionado a ter born senso ao escolher qual classe deve-se atribuir determinada responsabilidade. Em suma, o principio diz: sabe-se que tal classe possui tais atributos e metodos, entao pode-se dizer que esta classe "conhece" sobre determinado contexto, portanto ela deve ser uma boa candidata a receber uma nova responsabilidade relacionada corn este mesmo contexto. Esta classe e Especialista da Informacao. Problema: Como decidir a que classes atribuir responsabilidade? Objetivo: Atribua a responsabilidade ao Especialista da Informacao a classe que possui a informacao necessaria para possuir a responsabilidade. - Ao surgir a necessidade de uma nova responsabilidade no problema, deve-se analisar qual classe terd mais sucesso em armazenar to! informacao, baseandose no contexto que a classe "conhece". Especialista da Informacdo e padroes de projeto: A caracterizacao de urn determinado padrao de projeto e dada a partir da definicao de o que as classes relacionadas devem saber e o que elas nao devem. E necessario que esta premissa nunca seja violada. Por exemplo: imagine uma implementacao do padrao de projeto GoF Observer (Observador) onde o objeto observado saiba quem o esta observando. Isto invalidaria toda a implementacao. Desta maneira, faz todo o sentido compreender quem é especialista de qual informacao quando implementar urn padrao de projeto. Criador 0 principio Criador visa atribuir responsabilidades de criacao, que quando bem atribuidas, podem suportar Baixo Acoplamento, maior clareza, encapsulamento e reusabilidade. Problema: Qual classe deve ser responsavel por criar uma instancia de urn objeto? Solucäo: Atribua a classe B a responsabilidade de criar uma instancia da classe A se uma ou mais condicoes a seguir forem verdadeiras: B agrega objetos A; B contem objetos A; B armazena instancias de objetos A; B é dependente de objetos A; B possui dados de inicializacdo que sera passados a algum objeto A (fazendo assim B urn Especialista da Informacao em relacao a criar A). - Ao surgir a necessidade de criar uma instancia de urn objeto, deve-se analisar qual classe terd mais sucesso em criar o objeto, baseando-se em sua relacdo corn a classe do objeto a ser criado. Criador e padroes de projeto: Criador foi concebido para suportar a criacdo de objetos quando esta for justificavel na propria classe Criadora. Assim, este principio nä diz respeito quando ha necessidade de haver delegacao proposital da responsabilidade de criar instancias de outros objetos, onde aplicam-se padroes de projeto GoF criacionais como Factory e Builder (Construtor). No entanto, Criador pode ser aplicado a outro aspecto: quando deseja-se implementar urn padrao de projeto, quem deve instanciar cada um dos objetos que compaem o padrao? Por exemplo, no padrao de projeto GoF Prototype (ProtOtipo), o objeto Prototype cria instancias de si mesmo por clonagem. Portanto esta de acordo corn o principio Criador, pois os dados de inicializacao do objeto sao de conhecimento do proprio objeto. Agora, se atribuirmos esta responsabilidade a outro objeto, deveremos tambern divulgar os detalhes internos da classe Prototype a este objeto, aumentando o acoplamento deste objeto corn relacao ao Prototype, o que vai na contramao do principio Criador. Baixo Acoplamento Baixo Acoplamento é urn principio-chave na Orientacao a Objetos, que busca garantir que urn objeto/classe/subsistema/ sistema nao seja dependente de muitos outros. Esta dependencia se expressa quando urn esta conectado a outro, possui conhecimento sobre outro ou confia em outro. Uma classe corn alto acoplamento pode sofrer dos seguintes problemas: Mudancas nas classes relacionadas causam mudancas nas classes dependentes; Seu isolamento fica comprometido; Reuso complicado, pois requer a presenca adicional das classes relacionadas. 58 Java Magazine Edicäo 98

Problema: Como suportar baixa dependencia, baixo impacto a mudancas e alto reuso? Solucao: Atribua responsabilidades de maneira que o acoplamento permaneca baixo. - Ao atribuir responsabilidades, deve-se buscar manter o acoplamento baixo, evitando tornar urn objeto/classe/subsistema/sistema dependente de outro desnecessariamente. Baixo Acoplamento e padroes de projeto: 0 padrao de projeto GoF Mediator (Mediador) busca exatamente diminuir o acoplamento entre duas classes que variam independentemente. 0 mesmo ocorre em Business Delegate, quanto a separacao entre camadas de negocio e apresentacao. E importante observar o Baixo Acoplamento como uma motivacao obrigatoria ao se utilizar tais padroes. De maneira geral, nenhum padrao de projeto deve contribuir para urn alto acoplamento. Alta Coesao Alta Coesao é outro principio-chave na Orientacâo a Objetos, que anda de maos dadas corn o Baixo Acoplamento. Este principio busca garantir que um objeto/classe/subsistema/ sistema manipule suas pr6prias responsabilidades em seu devido escopo. Isto acontece quando ele possui urn conjunto de responsabilidades altamente relacionadas, e nao faz uma quantidade exagerada de trabalho. Uma classe corn baixa coes5o, que faz muitas coisas naorelacionadas ou executa muito trabalho, pode sofrer dos seguintes problemas: Dificil de compreender, reutilizar e ma nter; Constantemente afetada por mudancas. Problema: Como manter a complexidade gerenciavel? Soluck): Atribua responsabilidades de maneira que a coesào permaneca alta. - Ao atribuir responsabilidades, deve-se buscar manter a coeseio alta, garantindo que urn objeto/classe/subsistema/sistema possui responsabilidades altamente relacionadas e nao faz uma quantidade exagerada de trabalho. Alta Coesäo e padroes de projeto: 0 padrao de projeto GoF Chain of Responsibility (Cadeia de Responsabilidade) é urn born exemplo de Alta Coesao, pois concentra apenas que diz respeito as suas pr6prias responsabilidades e passa a requisicão adiante. Adicionar responsabilidade demais ou executar muito trabalho em urn determinado no da cadeia viola este principio, e naturalmente surge a necessidade de quebrar a cadeia, adicionando mais urn no a mesma. De maneira geral, nenhum padrao de projeto deve contribuir para uma baixa coesdo. Controlador Urn Controlador é urn objeto responsavel por manipular urn evento de sistema. 0 evento e gerado por urn ator externo, que por sua vez esta associado a realizacao de uma operacao do sistema. 0 Controlador busca aumentar o potencial para reutilizacao e possibilitar interfaces plugaveis. Normalmente, urn Controlador deve delegar o trabalho a ser feito a outros objetos. Ele nao e responsavel por realizar muito trabalho. Problema: Qual classe deve ser responsavel por manipular um evento do sistema? Solucdo: Atribua a responsabilidade por receber/manipular mensagens de evento do sistema a uma classe representando: urn sistema, dispositivo ou subsistema utilizando o padrao de projeto Facade; ou urn cenario de caso de uso onde o evento de sistema ocorre, nomeado em algo como <CasoDeUso>Handler, <CasoDeUso>Coordinator ou <CasoDeUso>Session. - Ao surgir a necessidade de manipular urn evento do sistema, deve-se atribuir tal responsabilidade a uma classe representando urn subsistema ou urn cendrio de caso de uso onde o evento de sistema ocorre, sempre delegando o trabalho a ser feito a outros objetos. Controlador e padreies de projeto: Podem-se enquadrar como Controladores os padroes que abstraem a delegacdo de eventos, como os padroes de projeto GoF Command (Comando) e Observer e os que representam subsistemas como o Facade. No entanto, deve-se compreender urn Controlador como urn mero coadjuvante a possibilidade de desplugar a interface atual e plugar uma interface diferente, sem impactar em como o sistema subsequente atende a eventos. Se isto rid() for possivel, nä temos um Controlador. Polimorfismo Traduzindo em milados, Polimorfismo é outro principiochave que visa oferecer uma abstracdo que aumenta a extensibilidade de uma classe, possibilitando Variaccies Protegidas e tambern proporcionando uma alternativa a logicas condicionais do tipo if-then-else. Alern disso, implementar Polimorfismo ira aumentar o nivel de Baixo Acoplamento e Alta Coesiio. Sua utilizacdo classica é quando em uma classe/interface generica e herdavel, criam-se metodos abstratos que sdo referenciados por classes relacionadas, caracterizando urn acoplamento desta corn a interface. Assim, qualquer classe que implementar corretamente a interface podera tomar seu lugar no referido relacionamento, sem efetivamente estar acoplada a classe relacionada. Problema: Como manipular condicionais baseados em tipo de dados ou classe? Como criar componentes de software plugaveis? Edicäo 98 Java Magazine 59

PadrOes de projeto, aprecie corn moderacao Solucdo: Quando condicionais ou comportamentos variam por tipo de dados ou classe, atribua responsabilidade ao comportamento - usando operacaes polimorficas - aos tipos nos quais o comportamento varia. - Ao manipular condicionais baseados em tipo de dados ou classe para a realizacäo de um dentre diversos comportamentos, deve-se considerar a utilizacdo de Polimorfismo, criando uma classe/interface generica e herdóvel com um mêtodo para representar o comportamento, que sera sobrescrito pelas subclasses. Polimorfismo e padroes de projeto: Muitos padroes de projeto GoF fazem uso de Polimorfismo, como Adapter (Adaptador), Command, Composite (Compositor), Proxy (Procurador), State (Estado) e Strategy (Estrategia). Polimorfismo e urn pri ncipio potente, que se nao for bem utilizado pode acrescentar complexidade dema is ao sistema. Ao utilizar Polimorfismo, defina claramente todas as abstracoes a serem utilizadas, e geralmente nao e muito prudente implementar uma camada de abstracao em um cenario que nao possua variacao polimorfica. se abusado, visto que se esta introduzindo uma classe estranha ao dominio do problema. Indirecao 0 principio da Indirecao nao tern segredos, significa simplesmente delegar responsabilidades a classes auxiliares, que muitas vezes sac) baseadas ern Fabricaccio Pura. Diz urn famoso adagio: "A maioria dos problemas na Ciencia da Computacao podem ser resolvidos adicionando mais urn nivel de indirecao.". Problema: Como atribu it responsabilidades e evitar acoplamento direto entre dois ou mais elementos? Cot-no relacionar objetos de maneira que suporte o Baixo Acoplamento e mantenha o potencial de reuso alto? Solucdo: Atribua a responsabilidade a urn objeto intermediario para mediar entre diversos componentes ou servicos, de maneira que eles nä fiquem diretamente acoplados. - Ao surgir a necessidade de atribuir responsabilidades e evitar acoplamento entre dois ou mais elementos, deve-se atribuir a responsabilidade a um objeto intermedidrio para mediar entre diversos componentes ou servicos. Fa bricacd o Pura 0 princfpio de Fabricacao Pura é urn artiffcio utilizado para manter as classes de dominio corn Alta Coesdo e manipular as classes do sistema corn Baixo Acoplamento. Tipicamente, chega-se a uma Fabricacao Pura por decomposicao representacional - quando a classe conveniente esta relacionada corn a organizacao de ideias e informacoes do dominio do problema, como um Pool de usuarios - ou cornporta mental - quando a classe conveniente esta relacionada corn urn comportamento inerente do sistema, que geralmente nao esta relacionado corn o dominio do problema, como urn algoritmo. Problema: Qual objeto deve possuir a responsabilidade, quando nao se deseja viola r a Alta Coesiio e o Baixo Acoplamento, mas a solucao oferecida por Especialista da Informacao é inapropriada? Solucäo: Atribua urn conjunto de responsabilidades corn Alta Coesdo a uma classe de conveniencia que nao representa urn conceito do dominio do problema - algo feito corn a proposta de suportar Alta Coesdo, Baixo Acoplamento e reuso. - Quando new ha uma solucao adequada a um problema de atribuicâo de responsabilidades no dominio do problema, deve-se criar uma classe de conveniéncia que nä representa um conceito do dominio do problema, mas que possa receber as responsabilidades suportando Alta Coesào, Baixo Acoplamento e reuso. Fabricacao Pura e padroes de projeto: Todos os pad roes de projeto sac) baseados ern Fabricacdo Pura. E urn recurso muito util ao desenvolvedor, no entanto, deve ser utilizado de maneira gradual e corn clareza, pois pode comprometer a complexidade do sistema Indirecáo e padr6es de projeto: Muitos padroes de projeto GoF fazem uso direto do conceito de delegacao, como Adapter, Bridge (Ponte), Facade, Mediator, e Proxy (Procurador). No entanto, deve-se ter parcimonia ao utilizar delegacoes, pois quanto mais indireta for uma requisicao, mais complexo o sistema sera, mais dificil sera de se depurar e a performance pode ser afetada. Diz urn famoso contra-adagio: "A maioria dos problemas de performance podem ser resolvidos removendo mais urn nivel de indi recao!". VariacOes Protegidas VariacOes Protegidas e mais um principio-chave que motiva o uso da maioria dos mecanismos e padroes a fornecer flexibilidade e protecao contra variacties, como encapsulamento de dados, interfaces, Polimorfismo e Indirecao. Vale definir dois tipos de pontos de muclanca: Ponto de variacao: variackies no sistema atual ou nos requisitos, que devem ser suportadas; Ponto de evolucao: pontos de variacao especulativos que podem ou nao aparecer no futuro, mas nä estao presentes nos requisitos atuais. Problema: Como projetar objetos, classes, subsistemas e sistemas de maneira que variacoes ou instabilidades nester elementos nao impactem ern outros elementos? Solucao: Identifique pontos de variacao ou instabilidade predita e atribua responsabilidades para criar uma interface estavel ao seu redor. - Ao surgir a necessidade de proteger pontos de instabilidade contra variaciies que certamente impactardo no funcionamento do sistema, deve-se criar uma interface est-at/el ao seu redor. 60 Java Magazine Ed icão 98

VariacOes Protegidas e padriies de projeto: Diversos pad roes de projeto GoF sdo motivados por Variaccies Protegidas, como Adapter, Command, Facade, Mediator, e Observer. Deve-se ter cautela ao lidar corn pontos de evolucão, pois certas vezes o custo de "previsao do futuro" é maior que o custo de uma implementacao simples que pode ser refatorada sempre que necessaria, assim que houver uma confirmacao quanto ao ponto de evolucao em questa. Assim, sugere-se sempre avaliar esta questa quando se for implementar um padrao de projeto motivado por VariacOes Protegidas. Consideraiiies gerais para desenvolver senso critico Como uma especie de checklist, o autor deste artigo preparou algumas perguntas a serem feitas no moment() de implementar urn padrao de projeto. Busque responder algumas delas mentalmente sempre que considerar incluir urn padrao de projeto, de maneira automatica. Note que as respostas podem diferir muito de urn contexto para outro. Com relacao a Padronizacdo x Complexidade: A insercao deste padrao de projeto vai adicionar complexidade demais ao sistema? Quais sera os elementos envolvidos? Eles ja sac) complexos o bastante para sugerir-se uma refatoracao antes da insercao deste padrao? Com relacao a Padronizacao x Aplicabilidade: Voce esta seguindo corretamente o que a documentacao do padrao de projeto diz quanto a aplicabilidade? 0 cenario atual encontra-se listado ou pode ser derivado da documentacao de aplicabilidade? Corn relacao a Padronizacão x Consequencias: Voce leu atentamente as consequencias que o padrao de projeto trara para o sistema? Voce e capaz de identificar u ma consequencia do sistema particular que voce esta trabalh a ndo que nao esta listada nesta documentacao de consequencias? Se ha consequencias, o sistema comporta a introducao das mesmas? Com relacao a Padronizacao x Utilidade: A arquitetura atual do sistema ja nao fornece maquinario suficiente, embutido em outras construcoes de codigo? E possfvel outro trecho de codigo do sistema aproveitar-se desta implementacao de padrao de projeto? Corn relacao a Padronizacao x Principios GRASP: A aplicacâo deste padrao de projeto esta em conform idade corn Os princfpios GRASP? Ha ao menos urn princfpio GRASP que apresenta alguma desvantagem quanto a implementacao deste padrao de projeto? Corn relacâo a Padronizacao x Performance: Imagine o seu codigo ern producao, em larga escala, recebendo m ilhares de requisiciies por minuto. A implementacao deste padrao de projeto podera afetar a performance do sistema? Conhecimento faz diferenca! Proses so. ateditio de Software: Um imps! ttttt engenharia %«. de software 11,,,A.A1:: Nenociatao de central, em proj engenharia ;;; de software tato,. as an. Doff nicoes, preocupacoes e custo Agilidade: Arompanhamento de projetos.gels distribuido atraves do Daily Meeting 221 engenharia ;«, de software. Ano SO., Processo e I...temente de requisites de negecios - Parte 2 Qualidade de Software DefinIgim caracterfsekts e Imporlanda 'Process e serem tornados automacdo de na Implantacho testes de Projeto Diagram. de seguiricla na prides Projet0 Como inserir padriies de projeto atravis de refatormiks - Parte 2 Faca um upgrade em sua carreira Em um mercado cada vez mais focado em qualidade, ter conhecimentos aprofundados sobre requisitos, metodologia, análises, testes, entre ouutros, pode ser a diferenca entre conquistar ou nao uma boa posicäo profissional. Sabendo disso a DevMedia lancou uma publicach totalmente especializada em Engenharia de Software. Todos os meses voce pode encontrar artigos sobre Metodologias Age's; Metodologias tradicionais (document driven); ALM (application lifecycle); SOA (aplicaciies orientadas a servicoes); Analise de sistemas; Modelagem; M6tricas; Orientacäo a Objetos; UML; testes e muito mais. Assine JS! (511dtedie de 'este funcional bd%eade em Cases de Uso - Pastes 5 a 9 leste Pr (...mo Execute testes funtiona is tom A importanda da comuniratio Hudson e Selenium RC no processo de software Faca já sua assinatura digital! I www.devmedia.com.br/es 123v-M cita

Padriies de projeto, aprecie corn moderacio Os recursos sac) corretamente utilizados e liberados em seguida pela implementacao do padrao de projeto? Corn relacao a Padronizacao x Refatoracdo: aconselhavel adiar a introducao de complexidade para quando realmente houver urn cenario mais complexo que o cenario consequente a implementacao deste padrao de projeto? Ao comparar a implementacao deste padrao de projeto corn uma solucao minima passivel de futura refatoracao, qual atende melhor o cenario atual, do ponto de vista da Engenharia de Software? Lembre-se que, hoje em dia, as metodologias âgeis incentivam a utilizacao de solucaes minimas e incrementais, pois geralmente sempre e possivel de se refatorar o codigo na proxi ma iteracao. Mesmo assim, é possivel considerar a inclusao de urn padrao de projeto ainda que nao se percebam os ganhos imediatos. Chandima Cumaranatunge nos conta em seu blog que Kent Beck the revelou que costuma acrescentar padroes "imediatamente antes deles se tornarem titeis". Ou seja, se voce nab consegue ver agora como sera Uteis, logo vera. Deste modo, padroes de projeto bem escolhidos podem sim ser introduzidos sem visualizar-se os beneficios imediatamente, desde que sejam bem justificados, por exemplo, por questoes como as apresentadas acima. Conclusiies O autor deste artigo nao acredita que tudo o que foi apresentado aqui seja o suficiente para alguem saber julgar perfeitamente a aplicacao de padroes de projeto. 0 objetivo deste artigo é apresentar discussoes para voce, leitor, considerar a reinterpretacao de certos conhecimentos, buscando acrescentar algo ao seu senso critico. Mesmo que haja discordancia corn o que foi apresentado, pelo menos alguma reflexao ou consideracao apresentada pode the ajudar a chegar a diferentes concluseies, e assim contribuir corn o seu entendimento sobre o assunto. Assim sendo, este artigo busca ajudar voce a extrair de si mesmo o conhecimento para a aplicacao de padroes de projeto corn moderacao. O real aprendizado deste assunto é ranico e individual, e nä. ha urn estudo disciplinado que o explicard minuciosamente, solucionando todas as dirvidas, assim como o estudo de Matematica, por exemplo. Este aprendizado esta mais para o estudo de Idiomas, onde assumimos certas premissas e sempre consideramos a possibilidade de erro, visto que somos seres humanos, e aprendemos licoes a partir destes erros, buscando que as nossas habilidades sejam continuamente aperfeicoadas. Se voce concordou, discordou, tern drividas ou quer discutir sobre algum ponto, sinta-sea vontade para entrar em contato corn o autor. Muito obrigado e ate a proxima! minicursos sobre o assunto. Tiago Romero Garcia tiagorga@gmailom Gerente de Engenharia, Eider Mcnico e Desenvolvedor Java Web na Avenue Code. Graduado em Ciència da Computack na UNIFEI e cursando Arquitetura de Sistemas Distribuidos na PUC Minas, SCJP e SCWCD, possui ampla experiència em padroes de projeto e já lecionou corej2eepatterns. corn Catalog de padrbes de projeto J2EE. antonioshome.net/blog/2006/20060906-1.php Antonio Vieiro descreve a doenca Singletonite em seu artigo "Singletonitis". c2.om/cgi/wiki?overuse0fpattems Catalog de anti-padroes relacionados corn o abuso de padrbes de projeto. e"'i oe5,9- as3dp.com/2009/09/03/integrating-design-patterns-just-before-they-becomeuseful Chandima Cumaranatunge explica como integrar padroes de projeto imediatamente antes de eles se tornarem titeis. De seu feedback sobre esta edic5o! A Java Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voce, leitor, acha da revista! Dé seu voto sobre este artigo, atraves do link: www.devmedia.com.bejavamagazine/feedback e,c.eedb,c4. 62 Java Magazine Edicäo 98