Construindo softwares utilizando Padrões de Projeto

Guilherme Eiji Ichibara - 10310700

Luccas Paroni Silva - 9285227

Thiago Benine Ferreira - 10377538

Construindo softwares utilizando

Padrões de Projeto

CONTEÚDO

INTRODUÇÃO

Origem e motivação ao uso

S.O.L.I.D.

Os padrões e as boas práticas

01

03

02

04

05

06

CLASSIFICAÇÃO

Os tipos de padrões de projeto

CRIACIONAL

Padrões Abstract Factory e Builder

ESTRUTURAL

Padrões Adapter e Proxy

COMPORTAMENTAL

Padrões Event-Subscriber e Mediator

INTRODUÇÃO

01

INTRODUÇÃO

01

Origem e motivação ao tema

ORIGEM

Padrões de Projeto —

Soluções Reutilizáveis

de Software

Orientado a Objetos

MOTIVAÇÃO

Construção de software

utilizando soluções

tentadas e testadas

S.O.L.I.D.

02

S.O.L.I.D.

02

Os padrões e as boas práticas

Single Responsibility

S

O

I

L

D

Liskov Substitution

Dependency Inversion

Interface Segregation

Open/Closed

CLASSIFICAÇÃO

03

CRIACIONAL

Os padrões criacionais fornecem mecanismos de criação

de objetos

ESTRUTURAL

Os padrões estruturais explicam como montar objetos e classes

em estruturas maiores

COMPORTAMENTAL

Padrões comportamentais são

voltados a designação de responsabilidades entre objetos

CLASSIFICAÇÃO

03

CRIACIONAL

04

CRIACIONAL

04

O PROBLEMA

04

_{O padrão Abstract Factory}

CRIACIONAL

Client

O PROBLEMA

04

_{O padrão Abstract Factory}

CRIACIONAL

Client

Botão PopUp Input

E se quisermos adicionar temas com

funcionalidades específicas?

O PROBLEMA

04

_{O padrão Abstract Factory}

CRIACIONAL

Client Botão Azul PopUp Azul Input Azul Botão Vermelho PopUp Vermelho Input Vermelho

A SOLUÇÃO

04

_{O padrão Abstract Factory}

CRIACIONAL

CreateButton() CreatePopUp()

ComponentFactory

A fábrica abstrata

É conhecida pelo código cliente

A SOLUÇÃO

04

_{O padrão Abstract Factory}

CRIACIONAL

CreateButton() CreatePopUp() IComponentFactory

A fábrica concreta

Des

conhecida pelo código cliente

Implementa os métodos de criação de elementos

Conhece apenas elementos de um tema

CreateButton() CreatePopUp()

A SOLUÇÃO

04

_{O padrão Abstract Factory}

CRIACIONAL

A interface de componente

Conhecida pelo código cliente

BlueButton

O componente Concreto

Desconhecida pelo código cliente

A SOLUÇÃO

04

_{O padrão Abstract Factory}

CRIACIONAL

BlueButton Button CreateButton() IComponentFactory CreateButton() BlueComponentFactory Client

CRIACIONAL

04

O padrão Abstract Factory

Button CreateButton() IComponentFactory CreateButton() BlueComponentFactory Client RedButton BlueButton CreateButton() RedComponentFactory

A SOLUÇÃO

CRIACIONAL

04

O padrão Abstract Factory

Quando usar esse padrão?

Sistema deve ser escalável

Objetos que devem ser utilizados de forma conjunta

Grande quantidade de objetos relacionados

PRÓS

Compatibilidade Desacoplamento P. da responsabilidade única P. do aberto/fechado

CONTRAS

Aumento de complexidade

CRIACIONAL

04

CRIACIONAL

04

CRIACIONAL

04

O padrão Builder

O PROBLEMA

Vehicule(wheels, motor, windows...) Vehicule

CRIACIONAL

04

O padrão Builder

A SOLUÇÃO

BuildDoors() BuildWheels() VehiculeBuilder BuildDoors() BuildWheels() CarBuilder BuildDoors() BuildWheels() BicycleBuilder Vehicule

Extraímos o código de construção para os objetos Builders

CRIACIONAL

04

O padrão Builder

A SOLUÇÃO

BuildDoors() BuildWheels() VehiculeBuilder BuildDoors() BuildWheels() CarBuilder BuildDoors() BuildWheels() BicycleBuilder Vehicule Construct() Director

Dessa forma, o código cliente

não precisa saber as

CRIACIONAL

04

O padrão Builder

Quando usar esse padrão?

Construtor telescópico

PRÓS

Reusar código de construção Construir objetos em etapas Responsabilidade única às classes de construção

CONTRAS

Aumento de complexidade

CRIACIONAL

04

O padrão Builder

ESTRUTURAL

05

ESTRUTURAL

05

O PROBLEMA

05

_{O padrão Adapter}

ESTRUTURAL

Como fazer com que interfaces incompatíveis se

comuniquem?

A SOLUÇÃO

05

_{O padrão Adapter}

ESTRUTURAL

O Adaptador

Converte a interface de uma classe

para outra, que o cliente espera

Quando usar esse padrão?

Possuir diversas subclasses, mas não é

prático adaptar sua interfaces

Interfaces incompatíveis

ESTRUTURAL

05

PRÓS

P. da responsabilidade única P. do aberto/fechado

CONTRAS

Aumento de complexidade

ESTRUTURAL

05

O padrão Adapter

ESTRUTURAL

05

O PROBLEMA

05

_{O padrão Proxy}

ESTRUTURAL

Você precisa controlar o acesso de um objeto,

por questões de segurança ou possui um objeto

muito custoso de ser criado?

A SOLUÇÃO

05

_{O padrão Proxy}

ESTRUTURAL

A SOLUÇÃO

05

_{O padrão Proxy}

ESTRUTURAL

O Cliente

Trabalha com os serviços e proxies pela

mesma interface

O Proxy

Segue a interface para se passar

como um objeto de serviço

Quando usar esse padrão?

ESTRUTURAL

05

O padrão Proxy

Inicialização preguiçosa (Proxy Virtual)

Controle de acesso (Proxy de Proteção)

PRÓS

Controle do objeto do serviço Gerenciar ciclo de vida

O serviço não precisa estar pronto P. do aberto/fechado

CONTRAS

Aumento de complexidade A resposta pode ter delay

ESTRUTURAL

05

COMPORTAMENTAL

06

COMPORTAMENTAL

06

O PROBLEMA

Como ser mais eficiente na comunicação ?

COMPORTAMENTAL

06

A SOLUÇÃO

Os interessados se inscrevem para serem notificados

COMPORTAMENTAL

06

A SOLUÇÃO

06

_{O padrão Event-Subscriber}

COMPORTAMENTAL

Uso de interfaces para não

acoplarmos às publicadoras

Quando usar esse padrão?

Listas de inscrição dinâmicas

Desconhecimento dos Inscritos

COMPORTAMENTAL

06

PRÓS

Relação em runtime P. do aberto/fechado

CONTRAS

Notificação em ordem aleatória

COMPORTAMENTAL

06

O padrão Event-Subscriber

COMPORTAMENTAL

06

O PROBLEMA

Como desacoplar esses componentes ?

COMPORTAMENTAL

06

A SOLUÇÃO

Restringir a comunicação direta

COMPORTAMENTAL

06

Quando usar esse padrão?

Elementos altamente acoplados

Alta dependência entre componentes

COMPORTAMENTAL

06

PRÓS

P. da responsabilidade única P. do aberto/fechado Redução de acoplamento Reutilização

CONTRAS

Mediador pode se tornar um “Objeto-Deus”

COMPORTAMENTAL

06

CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon, and infographics & images by Freepik.

Please keep this slide for attribution.

Ficou com alguma dúvida ou tem algum

questionamento ?

Sinta-se à vontade para perguntar

Abaixo estão listados os materiais utilizados para construir essa apresentação

Livros

■ Design Patterns: Elements of Reusable Object-Oriented Software, by Gamma Erich, Helm Richard, Johnson Ralph, Vlissides John and Grady Booch

■ Dive Into Design Patterns, by Alexander Shvets

Sites

■ https://www.dofactory.com/net/design-patterns ■ https://refactoring.guru/design-patterns