720 likes | 852 Views
Padrões de Design. Toacy Cavalcante de Oliveira. Problema. Análise vs Projeto. Análise Modela o mundo real. Usualmente não é “mapeável”para o Projeto pois tende a ser ineficiente/ineficaz. Projeto Atribuição de Responsabilidades. Boas práticas (+Coesão, -Acoplamento).
E N D
Padrões de Design Toacy Cavalcante de Oliveira
Análise vs Projeto • Análise • Modela o mundo real. • Usualmente não é “mapeável”para o Projeto pois tende a ser ineficiente/ineficaz. • Projeto • Atribuição de Responsabilidades. • Boas práticas (+Coesão, -Acoplamento)
Como compatibilizar os dois mundos? • Tipicamente, bons projetistas são formados após um longo período de experiência. • São hábeis praticantes do conceitos básicos de ES. • Abstração, Flexibilidade e Modularidade
Problema • Como capturar este conhecimento de modo a transmiti-lo a outros desenvolvedores para que estes também se tornem experts? • Design Patterns
Definições • “um padrão descreve um problema que se repete várias vezes em um determinado meio, descrevendo o núcleo de sua solução, de modo que esta solução possa ser usada milhares e milhares de vezes." [Christopher Alexander]
Definições • Os Padrões de Design formam um conjunto de regras que descrevem como realizar certas tarefas no âmbito do desenvolvimento de software [Pree, 1994].
Definições • Um Padrão de Design visa resolver um problema recorrente de design que surge em determinadas situações [Buschmann et al., 1996]. • Os Padrões de Design identificam e definem abstrações que estão acima do nível de uma única classe e de suas instâncias, ou de componentes [Gamma et al., 1994].
Motivação para DP • Novos problemas são geralmente similares a problemas já resolvidos anteriormente. • As soluções para problemas similares seguem padrões recorrentes.
Benefícios • Servem de guia para a solução do problema. • Ajudam a gerenciar a complexidade do software • Estimulam a aplicação e disseminação de boas práticas da POO. • Definem um vocabulário comum entre os projetistas, o que ajuda na disseminação de soluções bem sucedidas.
De onde vêm? • Christofer Alexander • A Pattern Language, Oxford University Press 1977 • Timeless way of Building, Oxford University Press 1979 • C.A. era arquiteto e identificou uma série de padrões utilizados na construção de edificações.
OOPSLA • Em 1987, Ward Cunningham e Kent Beck usaram algumas das idéias de Alexander no trabalho sobre GUI intitulado “Using Pattern Languages for Object-Oriented Programs” [OOPSLA-87].
Gang-of-Four • Em 1994, Erich Gamma, Richard Helm, John Vlissides e Ralph Johnson publicaram um dos livros mais importantes de Engenharia de Software da década de 90: “Design Patterns: Elements of Reusable Object-Oriented Software” [GoF].
Livros Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Addison-Wesley, October 1994
Descrevendo Padrões
4 Elementos Essenciais • Nome do padrão • Problema • Solução • Conseqüências
Nome • Serve de referência para o padrão. • Aumenta o vocabulário de projeto. • Deve ser único.
Problema • Quando aplicar um padrão. • Contexto. • Lista de condições que justifiquem aplicar o padrão.
Solução • Elementos que compõem o padrão. • “Arranjo” geral dos seus elementos. • Responsabilidades e colaborações destes elementos.
Conseqüência • Análises • Vantagens / desvantagens • Flexibilidade, capacidade de extensão ou portabilidade.
Identificação • Nome: Observer • Problema: Notificar a ocorrência de um evento a uma lista de objetos. • Solução: Observers delegam a responsabilidade de monitoramento para um objeto central o Subject. • Consequencias: Permite variar Subject e Observer de forma independente. Permite comunicação broadcast.
GoF & POSA • GoF (“the gang of four”) catalogue • “Design Patterns: Elements of Reusable Object Oriented Software,” Gamma, Helm, Johnson,Vlissides, Addison-Wesley, 1995 • POSA catalogue • Pattern-Oriented Software Architecture,Buschmann, et al.; Wiley, 1996
Estrutura do Catálogo • Classifica padrões de acordo com seu propósito, • De Criação • Estrutural • Comportamental • e escopo. • Objeto • Classe
Quanto ao escopo • Classes • Padrões tratam do relacionamento entre classes e subclasses; • Objetos • Padrões tratam relacionamentos entre objetos e por isso podem ser alterados em tempo de execução.
De Criação • Diz respeito ao processo ou ciclo de criação de um objeto. • Escopo classe: delega a criação de um objeto para alguma de suas subclasses. • Escopo objeto: delega a criação de um objeto para outro objeto
Estrutural • Diz respeito a composição de objetos e classes; • Escopo classe: Utilizam herança para compor objetos • Escopo Objeto: Descreve formas de compor objetos.
Comportamental • Caracteriza o modo como classes e objetos interagem e compartilham responsabilidades. • Escopo Classe: Utiliza herança para descrever algoritmos e controle de fluxo. • Escopo Objeto: Descreve como um grupo de objetos cooperam de modo a executar uma tarefa.
Estrutura Interna • Além das 4 características essenciais, o Catálogo do GoF define outras características para descrever padrões.
Estrutura Interna 1/3 • Nome do Padrão e Classificação • Passa a fazer parte do vocabulário dos projetistas. • Propósito • O quê o Padrão faz? • Que tipo de problema ou característica particular de projeto ele trata? • Também Conhecido Como: • Conjunto de outros nomes (apelidos) conhecidos para o Padrão, se existir algum. • Motivação • Um cenário que ilustra o problema de projeto e como as estruturas de classes e objetos no Padrão o resolvem.
Estrutura Interna 2/3 • Aplicação • Quais são as situações onde este padrão pode ser aplicado? • Quais são os exemplos de projetos que ele pode tratar? • Como você pode reconhecer estas situações? • Estrutura • Uma representação gráfica das classes no padrão • Participantes • As classes e/ou objetos que participam no padrão de projeto, e suas responsabilidades • Colaborações • Como os participantes interagem para cumprir suas responsabilidades
Estrutura Interna 3/3 • Conseqüências • Como o padrão alcança seus objetivos? • Quais são os resultados do uso do padrão? • Implementação • Dicas e técnicas que o projetista deve saber, e possíveis armadilhas para as quais ele deve estar preparado. • Exemplo de Código • Fragmentos de código que ilustram como o padrão deve ser implementado • Usos Conhecidos • Exemplos de utilização do padrão em sistemas já implementados. • Padrões Relacionados • Lista de alguns padrões fortemente relacionados ao padrão em questão e as suas principais diferenças.
O padrão Observer • Classificação • Comportamental de Objetos • Propósito • Provê sincronização, coordenação e consistência entre objetos relacionados. • Também Conhecido Como: • Dependents, Publish-Subscribe
Motivação • Necessidade de manter consistência entre objetos relacionados. • Não existe interesse em tornar as classes fortemente acopladas. • Ex. Planilha e gráfico de barras. • Não tem conhecimento um do outro • Trabalham em conjunto apresentando uma mesma informação • O padrão observer oferece um mecanismo para resolver esse problema • Subject Possui um conjunto de observers. • Notifica seus observers quando sofre uma mudança de estado
Aplicabilidade • Quando uma mudança em um objeto exige mudanças em outros, e não são conhecidos quantos devem ser mudados. • Quando um objeto deve ser capaz de notificar outros objetos sem que estes sejam fortemente acoplados.
Participantes • Subject • conhece seu Observer. Qualquer número de objetos Observer podem observar um Subject • provê uma interface para acoplar e desacoplar objetos Observer. • ConcreteSubject • guarda o estado de interesse para ConcreteObserver • envia uma notificação para seu Observer quando seu estado muda. • Observer • define uma interface de atualização para objetos que devem ser notificados sobre mudanças em um Subject. • ConcreteObserver • Mantém uma referência para um objeto ConcreteSubject • Guarda o estado que deve ficar consistente com o de Subject • Implementa o Observer atualizando a interface para manter seu estado consistente com o de Subject.
Colaborações • O ConcreteSubject notifica seus observadores sempre que ocorrer uma mudança. • Após ter sido notificado, um ConcreteObserver pode consultar o subject.
Conseqüências • Acoplamento fraco entre o Subject e o Observer • Suporte para comunicações em broadcast • Atualizações inesperadas
Implementação • Observando mais de um subject • Subject ativador é passado como parâmetro no método update() • Quem dispara a atualização? • Subject • Cliente
Usos conhecidos • Serviço de Eventos e Serviço de Notificação (CORBA)