Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Padrões de Projeto - Revista easy Java Magazine 13
Neste artigo abordaremos a história dos padrões de projeto no contexto da computação. Em seguida, daremos enfoque aos padrões GoF e como são usados em classes conhecidas do Java. Por fim, veremos como melhorar um sistema com a aplicação do padrã
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Easy Java Magazine 13
No cotidiano do profissional que atua no ramo da tecnologia, não é incomum se deparar com problemas arquiteturais recorrentes nos mais distintos sistemas de software. Nesse contexto, a experiência em resolver tais situações cotidianas é um fator importante que permite ao desenvolvedor de software uma maior habilidade para criar estruturas mais flexíveis e escaláveis que são de fácil entendimento para outros profissionais que atuem futuramente sobre ela. Em geral, essa experiência agregada é um diferencial capaz de produzir aplicações melhores, menos custosas em relação à manutenção posterior e com maior probabilidade de atingirem um determinado objetivo inicial pré-estabelecido. No sentido de compartilhar essa experiência inerente ao desenvolvimento de aplicações melhores é que surgiram os primeiros estudos sobre padrões de projeto.
Os padrões de projeto estão enraizados nas pesquisas realizadas pelo arquiteto e urbanista austríaco chamado Christopher Wolfgang Alexander. Ele foi responsável pela constatação, através de observação sobre inúmeras cidades medievais, da existência de padrões que as tornavam mais harmoniosas e belas. O interesse dele em traduzir tais padrões em maneiras de fácil entendimento para a aplicação em projetos de construção futuros ou melhoria dos pré-existentes resultou na publicação, em 1977, do seu livro mais famoso: “A Pattern Language: Towns, Buildings, Construction”. Nesse livro, ele enumerou as regras e fez o uso de ilustrações para promover métodos exatos para construir desenhos práticos, seguros e atrativos que poderiam ser reaplicados para os projetos de construção. Um dos grandes benefícios dessa obra foi que, ao tornar os padrões reusáveis, serviu como grande auxiliar na tomada de decisões de arquitetura. Essa característica inspirou engenheiros da computação e pesquisas aplicadas a software.
O termo “padrão de projeto”, no contexto da arquitetura de software, é considerado hoje como um efeito colateral da publicação do livro “Design Patterns: Elements of Reusable Object-Oriented” de Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Apesar disso, os primeiros trabalhos relacionados à pesquisa de padrões para a arquitetura de sistemas datam do final da década de oitenta, com as experimentações de Kent Back e Ward Cunningham, pioneiros da metodologia de desenvolvimento ágil de aplicações e da elaboração de aplicações baseadas em testes, Extreme Programming (XP) e Test Driven Development (TDD).
Esses trabalhos tinham o interesse comum de estudar e encontrar padrões em soluções amplamente empregadas em software para catalogá-las de maneira a torná-las uma base para uma situação equivalente futura. Assim, foram descritos os primeiros padrões de projeto para o desenvolvimento de sistemas.
O padrão de projeto nada mais é do que um modelo de uma experiência amplamente testada e aprovada que pode ser usado como um guia para a resolução de problemas específicos de arquiteturas orientadas a objetos. É uma alternativa reutilizável, baseada na abstração das escolhas bem sucedidas para atender uma dificuldade conhecida que é composta de quatro elementos essenciais: o nome, o problema que pretende resolver, a solução para o problema e as consequências da aplicação dele.
Os quatro elementos são decisivos para o sucesso de um padrão de projeto. Na grande maioria, os padrões descritos com melhor qualidade são de fácil interpretação e possuem uma grande capacidade de nos remeter aos benefícios de sua aplicação. Por exemplo, vejamos uma abstração de padrão do ponto de vista de Christopher: a solução para atravessar por dentro de uma montanha seria a construção de um túnel. O “Túnel” é um excelente nome de um padrão porque pode ser reconhecido por todos os envolvidos no projeto da construção, é também uma forma que já nos lembra do problema, ou seja, que uma montanha impede uma passagem e que também já nos leva a uma solução: a escavação. Além disso, ainda indica alguns benefícios, como não ter a necessidade de usar uma maior quantidade de recursos para construir uma via alternativa no entorno dela.
Atualmente, a quantidade de padrões de projeto identificados e catalogados em diferentes obras é provavelmente incalculável. Afinal, existem muitas situações onde existem padrões aplicados e que poderiam ser estudados. Não à toa, encontramos padrões para instanciar objetos, para lidar com problemas de concorrência ou até para construir web services. Entre eles, os mais conhecidos são os padrões GRASP (General Responsibility Assignment Software Patterns), estudados por Craig Lerman, e os padrões de projeto “GOF”."
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Felipe Pierin
bacharel em Sistemas de Informação pela Universidade de São Paulo, desenvolvedor Java para a Web e especialista em desenvolvimento orientado a testes e boas práticas de programação. Escreve artigos para revistas especializadas e publica periodicamente dicas de programação no seu blog pessoal em oreb...
2 COMENTÁRIOS
