OOD - Princípio da Inversão de Dependência

910 visualizações

Publicada em

Mais um slide usado nos hangouts da série OOD.

Publicada em: Tecnologia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
910
No SlideShare
0
A partir de incorporações
0
Número de incorporações
9
Ações
Compartilhamentos
0
Downloads
9
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

OOD - Princípio da Inversão de Dependência

  1. 1. Hangout OOD – Princípio da Inversão de Dependência 01/07/2014
  2. 2. Participantes: • João Batista Neto - Hoster • Augusto Pascutti - Moderador • Priscila Mayumi Sato – Slider maker • Ivo nascimento – Controlador do chat • Luís Otavio • Henrique Moody • Daniel Ribeiro
  3. 3. Pauta • Resumo rápido dos hangouts anteriores • Abordar, com profundidade e exemplos, o princípio de design D.I.P. • O que é dependencia? • Diferenciar Injeção de Dependência e Inversão de Dependência • Ilustrar casos do mundo real • Pôs pauta: discutir exemplos enviados previamente por cobaias e responder dúvidas
  4. 4. Resumo anteriores
  5. 5. Princípio de design D.I.P
  6. 6. D.I.P. • “Impossível compreender o principio da inversão de dependência antes de compreender dependência. A dependência é um participante A precisar de participante B para cumprir com sua responsabilidade. É aquilo que eu preciso para fazer alguma coisa.” João • “As classes de alto nível não devem depender das classes de baixo nível. A inversão de dependência funciona para você poder casar um determinado tipo com outras partes, não precisar usar tipos primitivos e usar classes de alto nível” (Moody? Foi ele que disse? :p) • “Quando trabalhamos com classes concretas e precisamos mudar o comportamento da nossa aplicação precisamos mudar as nossas classes concretas, o que não é bom e viola os princípios citados anteriormente. Por isso precisamos lidar com interfaces, quanto mais abstração melhor para evitar lidar com as classes diretamente” Daniel
  7. 7. D.I.P. • “Vamos supor que temos uma classe que recebe uma outra classe que escreve um arquivo XML, essa estritamente relacionada com arquivos XMLs. Se eu precisar um novo formato de texto eu preciso alterar a classe cliente, sendo eu preciso escrever um novo método. É essa a abstração de que estamos falando agora” Moody • “Uma das coisas mais difíceis de se entender é o conceito de abstração. Assim podemos falar além do ambiente de software. Falando ‘mesa’, cada um pode pensar em uma mesa, o João pensa numa mesa diferente da mesa que a Thamara pensa. Todo mundo aqui sabe o que é uma mesa, mesmo sem saber quantos pés tem, qual a cor, de que material é feito. Em software podemos pensar nos comportamentos mesmo sem pensar em detalhes. No caso o exemplo da PDO é um exemplo da abstração de dependência” Daniel
  8. 8. D.I.P. • “Ao conversar sobre dependência costumo analisar o cenário também. Por exemplo: dados transacionais são usados em bases de dados relacionais, por isso o Doctrine por exemplo abstraiu o problema de base de dados relacional. Mesmo sendo uma solução para dados transacionais, mas é uma abstração para o cenário especifico.” João • “Qual as consequências de um software depender de implementações: as implementações mudam! Por exemplo você trabalha com mysql e precisa mudar para uma base oracle. A mudança de servidor quebrou a sua aplicação. Ela era rígida ao depender da implementação. • Você ganha ao não depender em estabilidade e flexibilidade.” João
  9. 9. D.I.P. • “Duas coisas sobre software: o software muda. A grande probabilidade de seu softwarer ter bug. • Vivemos em um mercado muito acirrado, você precisa lançar features muito rápido, por isso quanto mais rápido você consegue mudar seu software mais você se mantém no mercado. Deixar seu software engessado atrapalha as mudanças e torna mais custoso as alterações. Depender de abstrações torna seu software mais fácil de se manter e escalável” João • “Precisamos tentar ao máximo entender o que estamos fazendo. O que o objeto faz, para que vamos usar ele. Quando falamos de inversão de dependência não devemos transitar as implementações, mas teremos as implementações. Classe tem seu contexto.” Moodysim, true
  10. 10. D.I.P. • “Exmplo: numa loja virtual eu quero saber o valor do total dos meus itens. Se no cara que faz a soma ele só sabe calcular o preço de um celular. Bom, o celular é uma única possibilidade. Ele pode calcular então qualquer coisa que tenha um preço, produto, serviço, etc. Então nesse meu processo eu recebo uma abstração de qualquer coisa que tenha um preço. Passando então qualquer coisa que tenha um preço pode ser passado para esse processo que segue a abstração.” Luiz • “”Alguns exemplos que falam de vida real tem problemas pois a vida real de desenvolvedores é diferente da vida real de não desenvolvedores. Quando usamos o exemplo da garrafa e liquido fica difícil de identificar comportamentos. Como comporta um liquido, uma garrafa? O líquido não interfere em como a garrafa vai se comportar. E orientação a objetos é relacionada a comportamentos.” João
  11. 11. D.I.P. • “Quando estamos falando de abstração estamos falando de abstração de comportamento e não de características.” João • “Exemplificando a classe de logger. Pensando em uma classe concreta que faz o log de um arquivo. O que significa inveter a dependência: é fazer a classe concreta também depender da implementação, a seta da dependência foi invertida.” Daniel • “
  12. 12. Exemplos
  13. 13. Pós pauta

×