45 pág.
Pré-visualização | Página 11 de 13
desenvolvimento de um soft ware. De acordo com Christopher Alexander (1977 apud GAMMA et al., 2000), “cada padrão descreve um problema no nosso ambiente e o núcleo da sua solução, de tal forma que você possa usar esta solução mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira”. O autor Christopher Alexander é o precursor dos trabalhos relacionados a padrões (patt erns). Ele é um arquiteto e matemáti co que fi cou muito conhecido, na década de 1970, pelos trabalhos desenvolvidos na criação de padrões geométricos e matemáti cos na área de arquitetura. Na década de 1990, quatro autores - Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides -, lançaram o primeiro catálogo de padrões de projeto, chamado livro GoF (Gang of Four). Desde então o desenvolvimento de projetos de soft ware fundamenta-se em terminologia e soluções baseadas nesse catálogo. Para Gamma et al. (2000), padrões de projetos são descrições de objetos e classes comunicantes que são customizados para resolver um problema geral de projeto num contexto parti cular. Segundo os autores, um padrão tem quatro elementos essenciais: • Nome do padrão: é uma referência que identi fi cará o problema de projeto, suas soluções e consequências. • Problema: descreve o problema e o contexto com o intuito de saber quando aplicar o padrão. • Solução: descreve os elementos que compõem o projeto, seus relacionamentos, suas responsabilidades e colaborações. • Consequências: são os resultados e a análise das vantagens e desvantagens (trade-off s) da aplicação padrão. Existem outros catálogos de padrões, tais como Padrões JEE, Padrões Microsoft , Padrões SOA etc. Eles são referências em seus respecti vos campos de atuação. Os padrões de projeto são representados por gráfi cos. Os objetos e classes são desenhados, e os seus relacionamentos, apresentados. Após essa notação gráfi ca, os códigos são especifi cados e explicados. Além dessa notação gráfi ca, é necessária uma descrição dos padrões de projeto. Nela são especifi cadas decisões, análise de custo-benefí cio, exemplos etc. Gamma et al. (2000) descrevem uma estrutura uniforme para essas informações: • Nome e classifi cação do padrão: nome do padrão e indicação da categoria dele. • Intenção e objeti vos: curta declaração das intenções e objeti vos do padrão. • Também conhecido como: outros nomes também uti lizados para o padrão, se existi rem. • Moti vação: cenário do problema e da solução de projeto por meio do padrão. • Aplicabilidade: situações de aplicação do padrão de projeto. • Estrutura: representação gráfi ca das classes do padrão. Podem-se uti lizar diagramas de interação. • Parti cipantes: classes e objetos que parti cipam do padrão de projeto e suas responsabilidades. • Colaborações: como os parti cipantes colaboram para executar suas responsabilidades. • Consequências: indicação das consequências da aplicação do padrão, como custo-benefí cio. • Implementação: informações relati vas à implementação do padrão de projeto, como linguagem de programação, dentre outras. Modelagem orientada a objetos com UML 36 • Exemplo de código: fragmentos ou blocos de códigos da implementação do padrão. • Usos conhecidos: exemplos do padrão encontrados em sistema reais. • Padrões relacionados: descrição dos padrões relacionados ao padrão uti lizado. Figura 35. Tirinha de humor sobre design patterns. Fonte: http:// vidadeprogramador.com.br/2011/07/08/design-patterns/. 1.2. Catálogo dos padrões de projeto GoF O catálogo de padrões GoF está dividido em três categorias: criação, estrutural e comportamental. Os padrões de criação são uti lizados para criar objetos. Os padrões estruturais preocupam-se com a composição de objetos e classes. Já os padrões comportamentais lidam com a interação de objetos e classes e suas responsabilidades. Além dessas categorias, Gamma et al. (2000), organizam o catálogo GoF em 23 padrões, conforme relação, em ordem alfabéti ca, descrita a seguir. 1. Abstract factory: fornece uma interface para a criação de famílias de objetos relacionados ou dependentes sem especifi car suas classes concretas. 2. Adapter: converte a interface de uma classe em outra esperada pelos clientes. O adapter permite que certas classes trabalhem em conjunto, pois, de outra forma, seria impossível, por causa de sua interfaces incompatí veis. 3. Bridge: separa uma abstração da sua implementação, de modo que as duas possam variar independentemente. 4. Builder: separa a construção de um objeto complexo da sua representação, de modo que o mesmo processo de construção possa criar diferentes representações. 5. Chain of responsibility: evita o acoplamento do remetente de uma solicitação ao seu desti natário, dando a mais de um objeto a chance de tratar a solicitação. Encadeia os objetos receptores e passa a solicitação ao longo da cadeia até que um deles a trate. 6. Command: encapsula uma solicitação como um objeto, permiti ndo que se parametrize clientes com diferentes solicitações, se enfi leire ou registre (log) solicitações e se suporte operações que podem ser desfeitas. 7. Composite: compõe objetos em estrutura de árvore para representar hierarquias do ti po partes-todo. O composite permite que os clientes tratem objetos individuais e composições de objetos de maneira uniforme. 8. Decorator: atribui responsabilidades adicionais a um objeto dinamicamente. Os decorators fornecem uma alternati va fl exível a subclasses para extensão da funcionalidade. 9. Facade: fornece uma interface unifi cada para um conjunto de interfaces em um subsistema. O façade defi ne uma interface de nível mais alto que torna o subsistema mais fácil de usar. 10. Factory method: defi ne uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe a ser instanciada. O factory method permite a uma classe postergar (defer) a instanciação às subclasses. 11. Flyweight: usa comparti lhamento para suportar grandes quanti dades de objetos, de granularidade fi na, de maneira efi ciente. 12. Interpreter: dada uma linguagem, defi ne uma representação para sua gramáti ca juntamente com um interpretador que usa a representação para interpretar sentenças nesta linguagem. 13. Iterator: fornece uma maneira de acessar sequencialmente os elementos de um objeto agregado sem expor sua representação subjacente. 14. Mediator: defi ne um objeto que encapsula a forma como um conjunto de objetos interage. O mediator promove o acoplamento fraco ao evitar que os objetos se refi ram explicitamente uns aos outros, permiti ndo que você varie suas interações independentemente. 15. Memento: sem violar a encapsulação, captura e externaliza um estado interno de um objeto, de modo que o mesmo possa, posteriormente, ser restaurado para esse estado. 16. Observer: defi ne uma dependência um-para-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são automati camente noti fi cados e atualizados. 17. Prototype: especifi ca os ti pos de objetos a serem criados usando uma instância prototí pica e cria novos objetos copiando este protóti po. 18. Proxy: fornece um objeto representante (surrogate), ou um marcador de outro objeto, para controlar o acesso ao mesmo. Modelagem orientada a objetos com UML 37 19. Singleton: garante que uma classe tenha somente uma instância e fornece um ponto global de acesso para ela. 20. State: permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecerá ter mudado sua classe. 21. Strategy: defi ne uma família de algoritmos, encapsula cada um deles e torna-os intercambiáveis. O strategy permite que o algoritmo varie independentemente dos clientes que o uti lizam.
