Tópicos Avançados em Linguagem de Programação Prof. Alexandre Vidal DEINF-UFMA Ciência da Computação Patterns (padrões) Compõem uma disciplina da Engenharia de Software voltada para a resolução de problemas origem na área de arquitetura de cidades e edificações baseada na documentação de melhores práticas e de lições adquiridas na prática. Padrões o objetivo do uso de padrões de software é criar uma base documental para ajudar na solução de problemas recorrentes em atividades de desenvolvimento ajudam a criar uma linguagem comum para compartilhar idéias e experiências sobre esses problemas e suas soluções
Padrões codificação formal das soluções e seus relacionamentos capturam o corpo de conhecimentos que definem boas arquiteturas para atender as necessidades de seus usuários uma linguagem de padrões comum permite a elaboração de raciocínio inteligível sobre mecanismos e estruturas de uma arquitetura Padrões um pouco de história Livros do arquiteto Christopher Alexander relacionados a planejamento urbano e arquitetura de edifícios (1964, 1975, 1977, 1979) Ward Cunningham and Kent Beck artigo apresentado no OOPSLA'87, Orlando, Florida, USA - "Using Pattern Languages for Object- Oriented Programs" Padrões um pouco de história Jim Coplien publica em 1991 um catálogo de idioms de C++ (um tipo de padrão específico de uma linguagem), Advanced C++ Programming Styles and Idioms Workshops da OOPSLA relevantes para o amadurecimento dos padrões de software: 1990-1993
Padrões um pouco de história 1995 - Livro Design Patterns: Elements of Reusable Object-Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, e John Vlissides (referidos como the Gang of Four ou GoF) 2000 - Pattern-Oriented Software Architecture: A System of Patterns (the POSA book). Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, e Michael Stal Padrões Um padrão é uma informação identificada que apreende e comunica a essência de uma solução aprovada de um problema recorrrente dentro de um certo contexto. Características de um bom padrão: resolver um problema ser um conceito provado e aprovado não ser uma solução óbvia descrever estruturas e mecanismos mais profundos e os seus relacionamentos
Algo só é considerado um padrão após se verificar ter sido usado em pelo menos três sistemas A revisão por terceiros é decisiva para uma proposta ser considerada um padrão pela comunidade Um padrão deve descrever como a solução equilibra ou resolve suas forças e porque essa é uma boa resolução de forças. Um padrão deve ser útil usável usado Anti-patterns um padrão é parte do conjunto das boas práticas ; um anti-padrão integra o conjunto de lições aprendidas, devendo, portanto ser evitado anti-padrões não devem se limitar a identificar más práticas recorrentes, mas indicam como recuperar, refatorar, realinhar e reconstituir a partir das situações identificadas
Tipos de padrões padrões de análise (Martin Fowler) padrões organizacionais padrões arquiteturais padrões de projeto idioms Padrões Arquiteturais expressam uma organização estrutural fundamental ou esquema de sistemas de software provêem um conjunto de subsistemas predefinidos, suas responsabilidades e regras para organização do relacionamento entre eles exemplo: MVC (Model, View, Controller) Padrões de projeto (Design Patterns) provêem um esquema para refinar subsistemas ou componentes de um sistema de software, ou o relacionamento entre eles descrevem estruturas recorrentes de componentes conectados que resolvem um problema geral de projeto dentro de um contexto particular
Idioms um idiom é um padrão de baixo nível específico de uma linguagem de programação descrevem como implementar aspectos específicos de componentes ou de seus relacionamentos usando características de uma determinada linguagem Elementos de um padrão nome problema contexto forças solução exemplos contexto resultante padrões relacionados usos conhecidos Nome deve ser significativo para permitir que uma palavra ou frase simples possa referir o conhecimento e a estrutura descrita pelo padrão bons nomes compõem um vocabulário para discussão de abstrações conceituais um padrão pode às vezes ter mais de um nome reconhecido e usado na comunidade (Also Known As)
Problema Uma declaração do problema descreve metas e objetivos desejáveis em um dado contexto e forças atuantes forças freqüentemente se opõe aos objetivos e umas às outras Contexto precondições sob as quais o problema e sua solução são recorrentes, e para as quais a solução é desejável é relacionado à aplicabilidade do padrão pode ser pensado como a configuração inicial do sistema antes do padrão ser aplicado Forças descrição das forças e restrições relevantes e como elas interagem e conflitam entre si e com as metas que se desejam alcançar forças definem os tipos de trade-offs que devem ser considerados na presença de tensão ou dissonância que elas criam
Solução relacionamentos estáticos, regras e comportamentos dinâmicos descrevendo como atingir a meta desejada pode incluir figuras, diagramas e texto para identificar a estrutura do padrão, seus participantes e colaborações variações ou especializações da solução também podem ser descritas Exemplos Uma ou mais aplicações do padrão para ilustrar: um contexto inicial específico como o padrão é aplicado e age sobre o contexto o contexto resultante da aplicação do padrão exemplos de fácil compreensão de sistemas conhecidos são normalmente preferidos Contexto resultante o estado ou configuração do sistema após a aplicação do padrão, incluindo: conseqüências (boas e más) problemas e padrões surgidos do novo contexto pós-condições e efeitos colaterais do padrão forças que foram resolvidas forças que não foram resolvidas quais padrões podem ser aplicados neste estágio
Argumentação explicação justificando passos ou regras no padrão, e do padrão como um todo, em termos de: como e porque ele resolve suas forças de um certo modo, para ser coerente com metas e princípios definidos como são orquestradas forças e restrições para obter uma harmonia adequada em resumo: como o padrão realmente funciona, porque ele funciona e porque ele é bom Padrões relacionados relacionamentos estáticos e dinâmicos entre um padrão e outros dentro de um mesmo sistema de padrões: predecessores: cuja aplicação conduz ao padrão em discussão successores: cuja aplicação segue do padrão em discussão alternativos: solução diferente para o mesmo problema, mas sob diferentes forças e restrições; codependentes: podem (ou devem) ser aplicados simultanemante com o padrão discutido. Usos conhecidos ocorrências conhecidas do padrão e sua aplicação em sistemas existentes ajudam a validar um padrão verificando que ele é, de fato, uma solução provada para um problema recorrente servem freqüentemente como exemplos didáticos
um arcabouço de software é uma mini arquitetura reutilizável que provê a estrutura e o comportamento genéricos para uma família de abstrações de software, dentro de um contexto de metáforas que especificam sua colaboração e uso em um dado domínio outra definição: um arcabouço é um conjunto de classes cooperantes que constituem um projeto reutilizável para um tipo específico de software um arcabouço provê um roteiro arquitetural ao particionar o projeto em classes abstratas definindo suas responsabilidades e colaborações
O desenvolvedor personaliza um arcabouço para uma aplicação específica derivando classes e compondo instâncias das classes do arcabouço o arcabouço dirige a arquitetura de uma aplicação: define sua estrutrura completa define seu particionamento em classes e objetos e suas principais responsabilidades define como classes e objetos colaboram define as threads de controle da aplicação o arcabouço captura decisões de projeto que são comuns ao domínio da aplicação portanto, arcabouços enfatizam reutilização do design sobre reutilização de código (embora costumem incluir subclasses concretas que podem ser usadas de imediato) um arcabouço pode ser visto como a implementação de um sistema de padrões de projeto contudo, um arcabouço é software executável, enquanto padrões de projeto representam conhecimento e experiência sobre software
arcabouços são a realização física de um ou mais padrões de software padrões são instruções sobre como implementar essas soluções principais diferenças entre padrões de design e arcabouços (segundo o livro da GoF): padrões de projeto são mais abstratos que arcabouços; arcabouços podem ser incorporados ao código, enquanto apenas exemplos de padrões podem ser parte do código padrões de projeto são elementos arquiteturais menores que arcabouções principais diferenças entre padrões de design e arcabouços (segundo o livro da GoF): um arcabouço típico contém diversos padrões de projeto, mas o inverso não é verdadeiro padrões de projeto são menos especializados que arcabouços arcabouços sempre têm um domínio de aplicação particular; em contraste, padrões de projeto podem ser usados em quase qualquer tipo de aplicação
Classificação de padrões por propósito padrões de criação ajudam a tornar um sistema independente de como seus objetos são criados, compostos e representados padrões estruturais se preocupam com a forma como classes e objetos são compostos para formar estruturas maiores padrões comportamentais tratam de algoritmos e da atribuição de responsabilidade entre objetos Classificação de padrões por escopo padrões de classe Lidam com relacionamentos entre classes e entre suas subclasses; São estabelecidos através da herança, sendo portanto estáticos A maioria dos padrões usa herança até certo ponto. Os únicos padrões considerados class patterns são aqueles com foco no relacionamento entre as classes padrões de objetos Lidam com relacionamentos entre objetos São mais dinâmicos (objetos podem ser mudados em runtime)
Padrões GoF (Metsker apud. notas de aula Helder Rocha) Referências Patterns and Software: Essential Concepts and Terminology by Brad Appleton http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html Components, Frameworks, Patterns Ralph E. Johnson. ACM SIGSOFT Symposium on Software Reusability (1997) http://citeseer.ist.psu.edu/johnson97components.html