Padrões de Projeto

Padrões de Projeto

INTRODUÇÃO

  • INTRODUÇÃO

  • O QUE É UM PADRÃO?

  • PADRÕES DE PROJETO

  • POR QUE USAR PADRÕES DE PROJETO?

  • PADRÕES GoF

  • O FORMATO NOS PADRÕES GoF

  • CATÁLOGO DE PADRÕES GoF

  • CATEGORIA DOS PADRÕES GoF

  • EXEMPLOS

  • COMO OS PADRÕES GoF RESOLVEM PROBLEMAS

  • PADRÕES GRASP

  • CATÁLOGO DOS PADRÕES GRASP

  • EXEMPLOS

  • CONCLUSÃO

  • REFERÊNCIAS BIBLIOGRÁFICAS

“Cada padrão descreve um problema no nosso ambiente e o núcleo de sua solução, de tal forma que você possa usar essa solução mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira.” [Alexander, 1977]

  • “Cada padrão descreve um problema no nosso ambiente e o núcleo de sua solução, de tal forma que você possa usar essa solução mais de um milhão de vezes, sem nunca fazê-lo da mesma maneira.” [Alexander, 1977]

  • Padrões de Projeto, Padrões Arquiteturais e Idiomas;

Estrutura de um padrão:

  • Estrutura de um padrão:

    • Nome;
    • Problema;
    • Solução;
    • Consequências.
  • Exemplo:

    • Nome: Chegar a apresentação de Projeto de Sistemas!
    • Problema: Você acordou tarde. Como chegar no horário da apresentação?
    • Solução: Corra pro ponto do BASA e tente encontrar espaço no ônibus.
    • Consequências: Você vai chegar amarrotado, suado e cansado para a apresentação.

Codificação flexível e reutilizável;

  • Codificação flexível e reutilizável;

  • Documentação organizada;

  • Maior compreensão do sistema;

  • Domínio da orientação a objeto.

Catalogados por Graig Larman, são padrões para atribuir responsabilidades para projetos de software.

  • Catalogados por Graig Larman, são padrões para atribuir responsabilidades para projetos de software.

  • O que são responsabilidades? “São contratos ou obrigações de um tipo ou classe” [PJR 97]

  • Responsabilidade não é um método.

  • Classificação:

    • Do tipo conhecer;
    • Do tipo saber.

PADRÕES RESTANTES

  • Polimorfismo

    • Problema: Como tratar alternativas baseadas em classes e tipos?
    • Solução: Nunca teste o tipo. Defina as alternativas em subclasses.
  • Invenção Pura

    • Problema: Como evitar que um objeto tenha muitas responsabilidades?
    • Solução: Crie uma nova classe que assuma parte das responsabilidades.
  • Indireção

    • Problema: Como evitar o acoplamento direto entre objetos que não devem ter conhecimento um do outro?
    • Solução: Use um objeto intermediário.
  • Não fale com estranhos

    • Problema: Quem irá evitar o conhecimento da estrutura de objetos indiretamente referenciados?
    • Solução: Atribuir responsabilidade a um objeto diretamente referenciado.

Creator (Criador)

  • Problema: Quem cria um determinado objeto X?

  • Solução: Atribua essa responsabilidade para uma classe Y se:

    • Y tiver alguma agregação ou composição com X;
    • Y possui uma relação de multiplicidade de um para muitos (1..*);
    • Y possui dados de inicialização que serão passados para X, quando este for criado;
    • Y usa X.
  • Consequência: Fraco acoplamento.

Creator (Criador)

Expert (Especialista)

  • Problema: Qual o princípio básico para atribuição de responsabilidades para as classes?

  • Solução: Atribuir responsabilidade ao especialista da informação, classe que tem a informação necessária para satisfazer a responsabilidade.

  • Consequência:

    • A encapsulação é mantida;
    • Fraco acoplamento e alta coesão.

Expert (Especialista)

Low Acoupling (Acoplamento Fraco)

  • Problema: Como suportar uma dependência baixa e aumentar a reutilização?

  • Solução: Atribuir a responsabilidade de forma que o acoplamento (dependência das classes) permaneça baixo.

  • Consequências:

    • Uma classe fracamente acoplada não é afetada por mudanças em outros componentes;
    • Mais simples de entender isoladamente;
    • Conveniente para reutilizar.

Low Acoupling (Acoplamento Fraco)

High Cohesion (Alta Coesão)

  • Problema: Como manter a complexidade sob controle?

  • Solução: Atribuir uma responsabilidade de forma que a coesão permaneça alta.

  • Consequências:

    • Objeto mais claro e compreensível;
    • Manutenção e melhorias simplificadas;
    • Acoplamento fraco;
    • Pouca quantidade de responsabilidade.

High Cohesion (Alta Coesão)

Controller (Controlador)

  • Problema: Quem deve controlar os eventos adicionados por atores externos?

  • Solução: Atribuir responsabilidade à classe controladora quando:

    • A classe representa todo o sistema ou um dispositivo;
    • A classe representa um caso de uso;
    • A classe representa algo no mundo real que é ativo.
  • Consequências:

    • Conhecer o estado do caso de uso;
    • Aumenta as possibilidades de obtenção de componentes reutilizáveis.

Controller (Controlador)

O objetivo básico do uso de padrões de projeto é de fornecer instrumentos necessários para a definição, o planejamento, o acompanhamento e o desenvolvimento de um projeto, visando a facilitação da análise e a correção de falhas que poderão surgir posteriormente.

  • O objetivo básico do uso de padrões de projeto é de fornecer instrumentos necessários para a definição, o planejamento, o acompanhamento e o desenvolvimento de um projeto, visando a facilitação da análise e a correção de falhas que poderão surgir posteriormente.

  • Por isso, a utilização dos padrões proporciona a edificação de aplicações e/ou codificação flexível além de documentação de soluções reaproveitáveis. A partir dos padrões de projeto é possível conhecer os pontos comuns entre diferentes soluções para o mesmo problema, que permitem o desenvolvimento de soluções melhores e eficientes.

BUSCHMANN, Frank; HENNEY, Kevlin; SCHMIDT, Douglas C. Pattern -Oriented Software Architecture – A pattern language for Distributed Computing. John Wileys and Sons, 2007.

  • BUSCHMANN, Frank; HENNEY, Kevlin; SCHMIDT, Douglas C. Pattern -Oriented Software Architecture – A pattern language for Distributed Computing. John Wileys and Sons, 2007.

  • HOFSTADER, Joseph. Usando Padrões para Definir uma Solução de Software – Construindo Aplicativos Distribuídos. In: Microsoft Developer Network, 2007.

  • GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padrões de Projeto – Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre. Bookman, 2000.

  • LARMAN, Craig. Utilizando UML e Padrões – Uma introdução à análise e ao projeto orientado a objetos. Porto Alegre. Bookman, 2000.

  • Pattern-Oriented Software Architecture. Disponível em: <http://www.cs.ucl.ac.uk/staff/ucacwxe/lectures/3C05-03-04/POSA.pdf>. Acessado em: 07 jun 2009.

Comentários