O GoConqr está de visual novo! Conte para nós o que você achou.

Registre-se grátis

Flashcards

Padrões de Projeto

Anne Caroli Português 55 flashcards

Flashcards do conjunto (55)

  1. 1Padrões de ProjetoObjetivo: registrar uma experiência no projeto de software, na forma de um padrão passível de ser efetivamente utilizado por projetistas
  2. 2Padrões de ProjetoCaracterísticas: busca de baixo acoplamento e alta coesão
  3. 3Padrões de ProjetoPropósitos:
    i. Criativo;
    ii: Estrutural;
    iii. Comportamental.
  4. 4Padrão CriativoAbstrai o processo de instanciação (criação) de objetos, ajudando a tornar um sistema independente de como seus objetos são criados, compostos e representados
  5. 5Padrão EstruturalDiz respeito a como classes e objetos são compostos para formar estruturas maiores
  6. 6Padrão ComportamentalDiz respeito a algoritmos e a atribuição de responsabilidades e comportamentos entre objetos
  7. 7Método FábricaPropósito: definir uma interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar. O método fábrica permite adiar a instanciação para as subclasses
  8. 8Método FábricaEstrutura:
    - ConcreteCreator
    - ConcreteProduct
    - Creator
    - Product
  9. 9Método FábricaPontos positivos:
    - Baixo acoplamento
    - Maior flexibilidade
    - Elimina a necessidade de acoplar classes específicas para aplicação em nível de cargo
  10. 10Método FábricaPontos negativos:
    - Alto número de classes
  11. 11Fábrica AbstrataPropósito: destinada à criação de uma família de objetos relacionados. Dessa forma, se todos os objetos relacionados forem obtidos a partir da mesma fábrica, não haverá inconsistência entre eles
  12. 12Fábrica AbstrataEstrutura:
    - AbstractFactory
    - ConcreteFactory
    - AbstractProduct
    - ConcreteProduct
    - Client
  13. 13Fábrica AbstrataPontos positivos:
    - Isola as classes concretas
    - Torna fácil a troca de famílias
    - Promove a harmonia entre produtos
  14. 14Fábrica AbstrataPontos negativos:
    - Difícil de suportar novos tipos de produto
  15. 15BuilderPropósito: permite criar diversos objetos semelhantes, utilizando o mesmo algoritmo
  16. 16BuilderEstrutura:
    - Builder
    - ConcreteBuilder
    - Director
    - Product
  17. 17BuilderPontos positivos
    - Permite variar a representação interna de um produto
    - Isola um código para construção e representação
    - Oferece um controle mais fino sobre o processo de construção
  18. 18BuilderPontos negativos
    - É preciso sempre chamar o método de construção para depois utilizar o produto em si
  19. 19SingletonPropósito: garante que apenas um objeto será criado e prover um único ponto de acesso para a esse objeto
  20. 20ProtótipoPropósito: especifica os tipos de objetos que serão criados através de protótipos e cria um novo objetivo copiando um protótipo
  21. 21ProtótipoEstrutura
    - Prototype
    - ConcretePrototype
    - Cliente
  22. 22ProtótipoPontos positivos
    - Acrescenta e remove produtos em produção
    - Especifica novos objetos pela variação de valores e estrutura
    - Reduz o número de subclasses
    - Configura dinamicamente uma aplicação com classes
  23. 23ProtótipoPontos negativos
    - Cada subclasse do Protótipo deve implementar a operação Clone, o que pode ser difícil
  24. 24AdaptadorPropósito: converte uma interface de um terceiro em uma interface que o programa entende
  25. 25AdaptadorEstrutura
    - Target
    - Cliente
    - Adapteer
    - Adapter
  26. 26AdaptadorPontos positivos
    - Permite a Adapter substituir algum comportamento da Adapteer
    - Introduz somente um objeto
    - Um único Adapter trabalhar com vários Adapteers
  27. 27AdaptadorPontos negativos
    - Um adaptador de objetos torna mais difícil redefinir um comportamento de Adaptee
  28. 28Peso MoscaPropósito: usar o compartilhamento para suportar de forma eficiente grandes quantidades de objetos
  29. 29Peso MoscaEstrutura
    - Flyweight
    - ConcreteFlyweight
    - UnsharedConcreteFlyweight
    - FlyweightFactory
    Cliente
  30. 30Peso MoscaPontos positivos
    - Um grande número de objetos podem ser substituídos por um grupo relativamente pequeno de objetos compartilhados
  31. 31Peso MoscaPontos negativos
    - Pode haver um grande custo na procura dos objetos compartilhados
  32. 32ObservadorPropósito: define uma relação de notificação de um para muitos, ou seja, quando um objeto muda seu estado, outros objetos são notificados de forma automática
  33. 33ObservadorEstrutura
    - Subject
    - Observer
    - ConcreteSubject
    - ConcreteObserver
  34. 34ObservadorPontos positivos
    - Acoplamento abstrato entre subject e observer
    - Suporte para comunidade do tipo broadcast
  35. 35ObservadorPontos negativos
    - Atualizações inesperadas
    - O protocolo simples de atualização não fornece detalhes sobre o que mudou no subject
  36. 36CompositePropósito: tem o objetivo de permitir que a mesma abstração possa ser utilizada para uma instância simples e para seu conjunto
  37. 37CompositeEstrutura
    - Component
    - Leaf
    - Composite
    - Client
  38. 38CompositePontos positivos
    - Define hierarquias de classe que consistem de objetos primitivos e compostos
    - Torna o cliente mais simples
    - Torna mais fácil de acrescentar novas espécies de componentes
  39. 39CompositePontos negativos
    - Pode tornar o projeto excessivamente genérico
  40. 40Cadeia de ResponsabilidadePropósito: evitar a acoplamento do sender de uma requisição com os receiver que irá tratar a requisição. A cadeia de receiver irá passar a requisição até um objeto tratar a requisição
  41. 41Cadeia de ResponsabilidadeEstrutura
    - Handler
    - ConcreteHandler
    - Client
  42. 42Cadeia de ResponsabilidadePontos positivos
    - Acoplamento reduzido
    - Flexibilidade adicional na atribuição de responsabilidades a objetos
  43. 43Cadeia de ResponsabilidadePontos negativos
    - A recepção não é garantida
  44. 44Template MethodPropósito: define o “esqueleto” de um algoritmo em um método, utilizando as subclasses como etapas para o algoritmo. Define alguns métodos e deixa alguns para a classe concreta implementar.
  45. 45Template MethodEstrutura
    - AbstractClass
    - ConcreteClass
  46. 46Template MethodPontos positivos
    - Facilidade de alteração do algoritmo principal
    - Técnica fundamental para reutilização de código
    - Particularmente importantes em bibliotecas de classe
  47. 47Template MethodPontos negativos
    - Se for preciso definir muitas operações nas subclasses, talvez seja necessário refatorar o código ou repensar o design
    - Não é possível proteger o método que executa o algoritmo genérico das subclasses
  48. 48EstratégiaPropósito: permite que o cliente mude o algoritmo de um objeto que utiliza uma função
  49. 49EstratégiaEstrutura
    - Strategy
    - ConcreteStrategy
    - Context
  50. 50EstratégiaPontos positivos
    - Podem fornecer diversas implementações do mesmo comportamento
    - Eliminam comandos condicionais da linguagem de programação
  51. 51EstratégiaPontos negativos
    - Clientes devem conhecer diferentes Strategies
    - A interface de Strategy é compartilhada por todas as classes
  52. 52ComandoPropósito: encapsula uma requisição como um objeto, deixando que o cliente parametrize as requisições. Facilita a adição de novos comandos e permite guardar um histórico de execução
  53. 53ComandoEstrutura
    - Command
    - ConcreteCommand
    - Client
    - Invoker
    - Receiver
  54. 54ComandoPontos positivos
    - É possível montar comandos para formar um comando composto
    - Fácil acrescentar novos Commands
    - Facilidade de extensão na arquitetura
    - Bom nível de desacoplamento
  55. 55ComandoPontos negativos
    - Complexidade dos comandos crescer demais

Informações

Descrição
FlashCards sobre Padrões de Projeto, criado por Anne Caroli em 25-06-2019.
Criado por
Anne Caroli
Visualizações
0
Avaliação

Mais sobre Padrões de projeto

Fale Conosco

Sobre o que é sua mensagem?

O que você acha do novo visual?

Você gostou?