Exemplo de problema, na prática, ao não se utilizar Injeção de Dependência
15/09/2016
0
E ai galera, tudo certo?
Bom, nos meus 2 anos de experiência em desenvolvimento asp.net c#, nunca usei injeção de dependência. Porém muito tem se comentado sobre isso e que ela resolve o problema de alto acoplamento entre as classes, onde não se pode usar classe concreta, blablabla....
Antigamente usava, por exemplo:
E vi que na injeção de dependência não se deve usar isso, pois a dependência deve ser de uma abstração, ou seja, uma interface, por exemplo. Até ai blz.
Mas pelas explicações, não consegui visualizar qual o problema que resolveria nos projetos que eu trabalhei, além daquelas explicações teóricos, "ah, mas vai resolver o problema de alto acoplamento, se eu mudar TAL coisa na classe, poderá dar problema no futuro por em TAL lugar estar dependendo dessa classe".
Alguém sabe elaborar um exemplozinho ou algum lugar que tenha um exemplo na prática qual o problema que a injeção de dependência resolve? Só para ficar mais claro na minha cabeça sobre isso.
Se a questão ficou confusa, estou aqui para tentar explicar mais minha dúvida.
Desde já agradeço.
Bom, nos meus 2 anos de experiência em desenvolvimento asp.net c#, nunca usei injeção de dependência. Porém muito tem se comentado sobre isso e que ela resolve o problema de alto acoplamento entre as classes, onde não se pode usar classe concreta, blablabla....
Antigamente usava, por exemplo:
Pessoa objPessoa = new Pessoa()
E vi que na injeção de dependência não se deve usar isso, pois a dependência deve ser de uma abstração, ou seja, uma interface, por exemplo. Até ai blz.
Mas pelas explicações, não consegui visualizar qual o problema que resolveria nos projetos que eu trabalhei, além daquelas explicações teóricos, "ah, mas vai resolver o problema de alto acoplamento, se eu mudar TAL coisa na classe, poderá dar problema no futuro por em TAL lugar estar dependendo dessa classe".
Alguém sabe elaborar um exemplozinho ou algum lugar que tenha um exemplo na prática qual o problema que a injeção de dependência resolve? Só para ficar mais claro na minha cabeça sobre isso.
Se a questão ficou confusa, estou aqui para tentar explicar mais minha dúvida.
Desde já agradeço.
Priscila Souza
Curtir tópico
+ 0
Responder
Posts
13/11/2016
Fernando Vilhena
A abordagem correta, não seria resolver problema, e sim tornar sua aplicação mais flexível promovendo a agilidade.
Explico:
Ao iniciar o desenvolvimento de uma aplicação, a primeira coisa que devemos investigar nesta fase inicial como forma de minimização de riscos é a exploração do coração da aplicação, das partes mais complexas do negócio.
Uma situação é que neste momento de investigação, é prudente manter distância de aspectos tecnológicos, focando na organização e funcionalidades das partes mais sensíveis desta nova aplicação.
Sendo mais pragmático, acredito que o acesso ao banco, criação das tabelas, seja desnecessário para o momento.
Então, neste caso o fato de se apoiar em uma interface permite que você possa injetar qualquer objeto desde que sua implementação esteja apoiada nesta interface.
Um caso seria uma interface voltada para conexao do banco de dados que permitiria a implementação de um Mock de dados para testes sem a necessidade do banco. Uma vez passado este momento de investigação, bastaria mudar a configuração da injeção do mock para o banco oficial já criado, sem muito esforço.
Para saber mais sobre mock, recomendo a leitura abaixo:
https://www.devmedia.com.br/mocks-introducao-a-automatizacao-de-testes-com-mock-object/30641
Este que citei é apenas uma aplicação baseado no baixo acoplamento, que é apenas um dos aspectos abordados na modelagem de sistemas complexos.
Padrão de Projetos. (SOLID / GRASP)
Boas práticas.
Flexibilidade melhora a Agilidade, diminui o esforço total durante o ciclo de vida do software.(Economia $$$)
Um uso comum é que quando utilizamos interfaces ao invés de implementações
A parte que envolve maiores riscos para então descobrirmos se haverá recursos técnicos disponíveis suficiente que nos permita devemos buscar testar
Explico:
Ao iniciar o desenvolvimento de uma aplicação, a primeira coisa que devemos investigar nesta fase inicial como forma de minimização de riscos é a exploração do coração da aplicação, das partes mais complexas do negócio.
Uma situação é que neste momento de investigação, é prudente manter distância de aspectos tecnológicos, focando na organização e funcionalidades das partes mais sensíveis desta nova aplicação.
Sendo mais pragmático, acredito que o acesso ao banco, criação das tabelas, seja desnecessário para o momento.
Então, neste caso o fato de se apoiar em uma interface permite que você possa injetar qualquer objeto desde que sua implementação esteja apoiada nesta interface.
Um caso seria uma interface voltada para conexao do banco de dados que permitiria a implementação de um Mock de dados para testes sem a necessidade do banco. Uma vez passado este momento de investigação, bastaria mudar a configuração da injeção do mock para o banco oficial já criado, sem muito esforço.
Para saber mais sobre mock, recomendo a leitura abaixo:
https://www.devmedia.com.br/mocks-introducao-a-automatizacao-de-testes-com-mock-object/30641
Este que citei é apenas uma aplicação baseado no baixo acoplamento, que é apenas um dos aspectos abordados na modelagem de sistemas complexos.
Padrão de Projetos. (SOLID / GRASP)
Boas práticas.
Flexibilidade melhora a Agilidade, diminui o esforço total durante o ciclo de vida do software.(Economia $$$)
Um uso comum é que quando utilizamos interfaces ao invés de implementações
A parte que envolve maiores riscos para então descobrirmos se haverá recursos técnicos disponíveis suficiente que nos permita devemos buscar testar
Responder
Clique aqui para fazer login e interagir na Comunidade :)
