Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, graças às boas práticas e princípios exercitados nos cursos anteriores; mas você talvez não se sinta ainda confortável em lidar com cenários mais complexos, onde é difícil desenvolver software com código de qualidade com flexibilidade suficiente para facilitar a implementação de mudanças repentinas de requisitos. O objetivo deste curso é oferecer a você um aprofundamento em técnicas de programação orientadas a objetos pelo uso de padrões de projeto no contexto de desenvolvimento ágil. Os seguintes conceitos são apresentados neste curso: • Revisão de conceitos de orientação a objetos: abstração de dados, encapsulamento, herança e polimorfismo • Reúso por meio de herança: padrões Null Object, Template Method e Factory Method • Delegando comportamento com composição: padrões Strategy, Bridge, State e Observer • Composição recursiva: padrões Composite e Chain of Responsibility • Envolvendo objetos: padrões Proxy, Decorator e Adapter • Estratégias para criar objetos: padrões Static Fabric Methods, Singleton e Builder • Modularidade: padrão Dependency Injection Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar partes da aplicação Web final com o componente de gamificação enriquecido constantes do Trabalho de Conclusão da Especialização, aplicando onde apropriado alguns dos padrões apresentados neste curso durante a refatoração na prática TDD.
DI Design Pattern
Loading...
来自 Instituto Tecnológico de Aeronáutica 的课程
Desenvolvimento Ágil com Padrões de Projeto
40 个评分
从本节课中
Semana 4
Olá, bem-vindo ao Curso 5 – Desenvolvimento Ágil com Padrões de Projeto! Ao final deste módulo, você terá aprendido a criar objetos por meio dos padrões Abstract Factory e Builder. Você terá aprendido também uma forma de modularizar seu código com base no padrão de projeto Dependency Injection. Ao final, você irá exercitar parte do conhecimento aprendido neste curso ao desenvolver uma pequena aplicação com gamificação!
与讲师见面
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] [MÚSICA] Olá.
Bem vindo ao curso Desenvolvimento Ágil com Padrões de Projeto.
Eu sou Clovis Fernandes.
Hoje iremos apresentar o padrão de projeto Injeção de Dependência.
Nós estávamos falando sobre o conceito de injeção de dependência,
o contexto que ele se situa.
Hoje iremos falar sobre o padrão, quer dizer, nós vamos falar sobre o padrão,
nós vamos querer modularizar este
conjunto de consumidor,
serviço dentro de cada contexto para que eu possa reusar,
trabalhar isso melhor, testar melhor através do JUnit,
enfim, ter código mais limpo.
Vamos recapitular o que a gente viu então sobre injeção de dependência.
Que simplesmente nós basicamente trabalhamos com dois tipos:
a injeção por construtor, ou a injeção por setter.
O que mais está envolvido?
O serviço, o consumidor e o contexto.
Isso ainda não caracteriza, nós vimos, né,
padrão de projeto para a injeção de dependência.
Para tornar as coisas mais modulares, o código mais limpo.
Nós vimos que falham aqueles três objetivos que a gente disse que
seriam para padrão DI, padrão de injeção de dependência,
padrão de projeto correspondente.
Vamos olhar agora.
Neste contexto eu estou chamando de rumo ao padrão de projeto de
injeção de dependência, nós já começamos resolver,
a satisfazer alguns dos problemas que os contextos anteriores apresentavam.
Por exemplo, nós colocamos agora aqui uma interface chamada
ServiçoMensagem e eu vou implementar o ServiçoEmail de acordo com esta interface.
O que aconteceu aqui?
Eu quebrei aquela dependência que o consumidor tinha com o ServiçoEmail aqui.
Eu quebrei isto.
Ou seja, agora eu faço uma injeção de tal forma que o
consumidor fica ali no call center.
Ele nem sabe que é o ServiçoEmail.
Então se eu colocar aqui novo serviço SMS, por exemplo, ele não vai saber dado
momento se é o de e-mail ou do SMS, porque ele só conversa com a interface.
Então eu posso crescer deste lado aqui, ou seja, o lado do consumidor
neste contexto aqui eu consigo fazer inserção de novos serviços.
Então a OCP aqui eu estou estendendo, eu atendo novos serviços,
poderia estender para ter novos serviços e não vai haver modificação nenhuma do
código do consumidor, nem do cliente, porque o cliente também não está
dependendo aqui do ServiçoEmail ou da interface de ServiçoMensagem.
Agora vamos ver o lado do cliente.
O cliente agora continua dependendo do consumidor,
mas ele agora depende do injetor do ServiçoEmail.
Então o que nós construímos neste padrão?
Agora existe uma classe intermediária que faz duas coisas ao mesmo tempo.
Ele, seguindo pela numeração aqui, o número dois aqui,
ele cria o serviço, que no caso só temos serviço e-mail neste momento,
embora esteja desacoplado, a criação do serviço está totalmente
desacoplada da criação do consumidor, está certo?
Aí, logo seguida, no número três aqui, ele cria o consumidor.
Se ele está usando a injeção de dependência pelo construtor,
ele já vai injetar o serviço na hora de criar o consumidor aqui.
No passo quatro ele injeta, mas pode ser ao mesmo tempo, está certo?
Ele já injeta no objeto Consumidor que ele criou o serviço que ele tinha
recém-criado também.
Se ele estivesse fazendo por setter, ele cria o serviço,
cria o consumidor, injeta o serviço através do setter.
Tudo isso independente, o cliente nem está tendo ciência disso.
O que o cliente tem que fazer apenas?
Passos a seguir aqui.
Criar o injetor, que no caso é o injetor de ServiçoEmail.
Ao fazer isso, ele vai obter o consumidor.
Ou seja, ele vai pedir, por exemplo,
método de fábrica estático do injetor serviço.
Por exemplo, 'get consumidor' e ele obtém qual é o consumidor.
E aí seis ele usa o consumidor.
Se eu quiser criar novos serviços,
não tenho problema nenhum com relação ao consumidor.
Mas com relação ao cliente eu tenho, porque se eu criar serviço SMS,
eu vou precisar aqui de injetor para criar os dois serviços, tá certo?
O ServiçoSMS e o ServiçoEmail.
Este e-mail eu já tenho, o SMS seria criado aqui.
E o cliente tem que estar ciente disso aqui.
Como ele tem ciência do injetor,
eu vou ser obrigado a criar aqui uma interface para os dois aqui.
Ou seja, é rumo ao padrão de projeto de injeção
de dependência porque o objetivo a OCP, falha aqui.
Se eu aumentar novo serviço ali,
vai implicar na criação de injetor apropriado para este novo serviço.
Como eu já tenho injetor anterior, eu vou ter que criar uma interface de injetores.
Nesta tela nós estamos mostrando
que agora nós estamos rumo ao padrão de projeto de injeção de dependência.
Por isso que eu estou chamando agora ele não apenas só de DI, mas de DI DP,
Dependency Injection Design Pattern.
E para isso nós incluímos a interface
de serviço e injetor.
Ou seja, agora já estamos muito próximos do padrão DI.
Vamos dar uma olhada agora que nós completamos o padrão.
Inserimos novo serviço aqui,
isso com relação ao consumidor, nenhum problema.
Posso inserir quantos serviços eu quiser aqui.
Criei então novo ServiçoSMS e para isso criei injetor de ServiçoSMS.
Eu já tinha injetor de ServiçoEmail,
agora para isso eu criei uma interface e o cliente
agora depende apenas da interface InjetorServiçoMensagem.
Não depende mais diretamente de injetor,
porque isso era uma coisa, acoplamento muito concreto, tá certo?
Agora não, ficou acoplamento mais frouxo.
E ele continuam aqui a sua dependência do consumidor porque agora
eu vou criar injetor no nosso exemplo aqui,
eu vou usar o injetor, objeto InjetorServiçoSMS.
Primeira coisa que ele faz é criar o serviço, ServiçoSMS.
Depois ele cria o Consumidor,
e depois ele injeta esse serviço aqui no Consumidor.
Ou seja, se eu estiver usando a injeção de dependência do tipo por construtor,
assim que o serviço, logo seguida eu vou criar o Consumidor,
eu já passo o serviço como parâmetro aqui, tá certo?
Eu injeto aqui, para criar.
Se for por setter, vai depois.
A mesma coisa se eu estivesse fazendo a inserção do ServiçoEmail como
era o que foi feito anteriormente.
Com isso, agora, se eu criar novo serviço aqui,
basta criar novo injetor associado.
E eu não mudo nem o código do consumidor, nem o código do cliente.
Ou seja, nós conseguimos chegar no padrão do Design Pattern de injeção
de dependência, porque os três princípios estão sendo observados.
Por isso, nesta tela, vocês podem ver que agora nós temos todos
os componentes que fazem parte do DIDP,
do Padrão de Projeto de Injeção de Dependência,
que neste momento eu incluí também a interface de injetor.
Então nós termos o serviço, que era a dependência, nós temos o consumidor,
que consome, que é dependente da dependência Serviço, nós temos o contexto,
que é sempre algum cliente que depende desses
serviços que vão ser realizados pelo consumidor.
Nós temos a interface dos serviços,
porque aí a gente consegue agora ter mais do que serviço.
Nós temos os injetores para cada dos tipos de
serviço e a interface de injetores tornando o
contexto independente dos serviços, totalmente independente.
Então eu posso pôr agora novos serviços,
simplesmente eu crio novo serviço e injetor associado.
Pronto.
Mais nenhum código é modificado.
Com isso, nesse padrão, nós satisfazemos os objetivos
dois e três que nós estabelecemos para padrão de injeção de dependência,
padrão de projeto injeção de dependência.
O toda vez que eu incluir novos serviços,
eu incluo injetor correspondente
e então estou estendendo, então está aberto para extensão e
fechado para modificação porque não vai haver nenhuma modificação.
O segundo objetivo era satisfazer o norte.
Está aí.
Todas as classes conversam, todos os objetos das classes
conversam apenas com seus vizinhos, apenas com seus vizinhos.
Pronto.
Satisfazendo o [INCOMPREENSÍVEL] completamente.
E o 3, a criação dos objetos Serviços
é totalmente separada dos objetos Consumidores.
E era o que a gente queria.
Com isso cumprimos, mostramos para vocês o padrão completo,
o padrão de projeto de injeção de dependências.
Obrigado.
[MÚSICA] [MÚSICA]
