Please enable JavaScript.
Coggle requires JavaScript to display documents.
Padrões de projetos - parte 2 (Decorator (Prós e contras (Prós (Estender o…
Padrões de projetos - parte 2
Padrões estruturais
Projetar objetos que delegam responsabilidades a outros objetos
Arquitetura de camadas de componentes com baixo grau de acoplamento
Facilitar a comunicação
Diante de interfaces incompatíveis
Quando objetos não são acessíveis de formas normais
Decorator
Usado para estender a funcionalidade de um objeto dinamicamente sem ter que alterar a classe de origem ou usar herança
É feito usando um wrapper de objeto (decorator) em torno do objeto real
É projetado para ter a mesma interface do objeto oculto
Permite que o cliente interaja da mesma forma que faria com o objeto real
O decorator contém uma referência ao objeto real
O decorator recebe e encaminha as chamadas de clientes
O decorator adiciona funcionalidades antes e depois de encaminhar as solicitações (pode ser em tempo de execução)
Prós e contras
Prós
Estender o comportamento sem cria uma nova subclasse
Adicionar ou remover responsabilidades em tempo de execução
Você pode combinar vários comportamentos envolvendo um objeto e vários decorators
Princípio da responsabilidade única
Contras
É difícil remover um invólucro específico da pilha de invólucros
É difícil implementar um decorator de forma que seu comportamento não dependa da ordem na pilha de decorators
O código de configuração inicial pode parecer bastante feio
Adapter
Em algumas situações, pode ser difícil usar um serviço por causa da interface
Atualizar a interface pode trazer incompatibilidades com outros clientes já funcionando
O padrão Adapter sugere a definição de uma classe wrapper em torno do objeto com a interface incompatível
Duas formas: adaptador de classe, wrapper (adaptador de objeto).
O conceito Adapter pode ser usado para adaptar interface de classes e também de objetos
Prós e contras
Prós
Princípio da responsabilidade única
Princípio aberto/fechado
Contras
A complexidade geral do código aumenta
Composite (Object tree)
Permite compor objetos em estruturas de arvores e trabalhar com essas estruturas como se fossem objetos individuais
Faz sentido apenas quando o modelo principal do app pode ser representado como uma árvore
O padrão Composite sugere que você trabalhe com Products e Boxes através de uma interface comum que declare um método para calcular o preço total
Para um produto, basta retornar o preço do produto. Para uma caixa, ele examinaria cada item da caixa, perguntaria seu preço e retornaria um total para essa caixa