Artigos Java Design Patterns: Entendendo os padrões Singleton, Abstract Factory, Decorator e Strategy

Por que eu devo ler este artigo:Um dos principais problemas na adoção de padrões de projeto orientados a objetos é justamente decidir em que problemas eles devem ser aplicados.

Neste artigo, exploramos os fundamentos de padrões de projeto, explicando seus conceitos essenciais e abordando a utilização de quatro padrões do catálogo GoF para satisfazer alguns requisitos básicos em uma aplicação exemplo.

Ao realizarmos uma busca, encontraremos diversas definições para a palavra “padrão”. Essas definições, em geral, partem de um conceito central que é a busca por regularidade, repetição ou possibilidade de reprodução, mesmo que a repetição não seja exata ou perfeita.

Com esses pequenos conceitos em mente, podemos imaginar que um padrão é algo que fornece um gabarito para a realização de determinada ação ou tarefa. É um ponto de partida reproduzível, mas que pode ser estendido de acordo com o problema em que queremos aplicá-lo.

Na Engenharia de Software, o termo “Padrão de Projeto” (ou Design Pattern, em inglês) foi utilizado pela primeira vez por Kent Beck e Ward Cunningham, que se propuseram a experimentar as ideias sobre uma linguagem de padrões para projetos de construção civil que Christopher Alexander havia implementado na década anterior.

Alexander imaginava que os usuários sabiam mais sobre os prédios em que desejavam viver do que os arquitetos que os projetavam e, a partir dessa ideia central, desenvolveu padrões que possibilitariam a qualquer profissional projetar e construir prédios que se adequassem às necessidades mais comuns das pessoas.

Beck e Cunningham (que mais tarde ganhariam notoriedade pela sua participação na criação dos conceitos de Extreme Programming e do Agile) deram início à formalização do conceito de padrões de projeto, mas o termo ficou realmente popular com a publicação em 1994 do livro “Design Patterns: Elements of Reusable Object-Oriented Software” (sem tradução no Brasil, embora edições posteriores possam ser encontradas em Português), de autoria da chamada “Gang-of-Four” (GoF), formada inicialmente por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides (falecido em 2005).

Esse livro, que se tornou um clássico no ensino de programação em todo o mundo, dedica seus dois primeiros capítulos à exploração do potencial da programação orientada a objetos enquanto paradigma da computação. Na sequência, os autores descrevem os 23 padrões de projeto que viriam a compor o não menos clássico catálogo GoF.

A partir desse momento, com o estabelecimento de um catálogo consistente em uma publicação importante para a Ciência da Computação, os padrões de projeto passam a ser um conceito plenamente estabelecido na Engenharia de Software para designar soluções reusáveis para problemas recorrentes de projeto de software em um dado contexto, constituindo um conjunto de boas práticas de desenvolvimento orientado a objetos.

Com isso, diversos catálogos foram elaborados e diversos tipos de padrões foram desenvolvidos (vide BOX 1). Classificações apareceram para facilitar a organização dos padrões em seus respectivos catálogos e, claro, novas publicações surgiram a respeito do tema.

Uma vez que os exemplos demonstrados no livro da Gang-of-Four foram desenvolvidos utilizando a linguagem C++, não demorou até que as comunidades dedicadas a outras linguagens fizessem suas versões dos padrões do catálogo.

Diversos livros exploram a aplicação dos padrões do catálogo GoF em Java, dentre os quais gosto de destacar “Java Design Patterns”, de James Cooper – por seu caráter seminal em explorar a aplicação do catálogo GoF em Java e “Core J2EE Design Patterns: Best Practices and Design Strategies” (Core J2EE Design Patterns: As Melhores Práticas e Estratégias de Design), de Dan Malks, Deepak Alur e John Crupi – por sua abordagem pedagógica em relação ao tema.

BOX 1 Catálogos de Padrões

Catálogos são repositórios de padrões e, em geral, são mantidos por seus autores ou por grupos dos quais os autores dos padrões fazem parte. Em geral, os catálogos são relacionados a domínios de aplicação – ou contextos. Podemos destacar os populares catálogos Gang-of Four (GoF) e o General Responsibility Assignment Software Patterns (GRASP).

Em sua documentação, um padrão de projeto precisa explicar o motivo pelo qual as principais situações em que ele se aplica são problemáticas e, especialmente, por que a solução proposta pode ser considerada adequada.

Para o pessoal da Gang-of-Four, os problemas mais comuns em projetos de software surgem de conflitos, ou seja, de situações em que o objetivo vai de encontro com a ferramenta utilizada para alcançá-lo (por exemplo, curar um paciente vs. o risco de determinados remédios poderem matá-lo).

Esses fatores devem fazer parte da documentação do padrão e, em determinados casos, os autores explicam as suas principais aplicações.

Da mesma forma, se um padrão é utilizado recorrentemente de maneira não efetiva, ele se torna um Anti-padrão (vide BOX 2). Sendo assim, podemos assumir que o principal objetivo dos padrões é contribuir para a solução de problemas recorrentes de programação. No entanto, é preciso destacar que um padrão não é a solução em si, mas um “caminho” comum no qual a solução pode ser encontrada. O lado bom dessa história é que, um padrão catalogado signific ...

Quer ler esse conteúdo completo? Tenha acesso completo