Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Inversão de Controle

Inversão de Controle

Ainda é muito comum que desenvolvedores, mesmo os mais experientes, pequem no design das classes de uma aplicações tornando-as fortemente acopladas em implementações e não em abstrações. A proposta desta apresentação é falar sobre a importância do padrão IoC e DI e como o componente Symfony Dependency Injection pode auxiliar na implementação dessa boa prática.

Tales Santos

June 20, 2019
Tweet

Other Decks in Technology

Transcript

  1. Quem sou eu? Tales Santos Engenheiro de Software na MaxMilhas

    Github: @tsantos84 Twitter: @tales84 Violonista nas horas vagas
  2. Inversão de Controle (IoC) Padrão de desenvolvimento que passa o

    controle dos objetos a um contexto externo (framework ou container) Fino controle sobre implementações que serão injetadas Desacopla a execução de uma rotina da sua implementação Facilita os testes unitários
  3. Antes do IoC (new Registration)->register(new User()); Fácil e rápido para

    instanciar novos objetos Forte acoplamento com outros serviços Dificulta testes unitários Inflexível. Como trocar de StreamLogger para SlackLogger?
  4. Como Resolver? $registration = new Registration( new Mysql(new Pdo(…)), new

    Aws\Ses(…), new StreamLogger(‘/logs/app.log‘) ); $registration->register(new User());
  5. Como Resolver? Podemos utilizar dubles para testes unitários Princípio da

    inversão de dependência (DIP) aplicado Flexível. Posso utilizar SlackLogger ao invés de StreamLogger?
  6. Injeção de Dependência Permitir que um objeto seja responsável pela

    construção de outros objetos, controlando as implementações que serão injetadas no serviço a ser criado. • Centralização da construção de objetos (container) • Facilita instanciação dos objetos • Flexibilidade para alternar dependências • Pode ser uma forma de se aplicar o 
 padrão Singleton
  7. Antes do container Descentralização da construção dos objetos Tedioso processo

    de construção de objetos pois precisamos saber como os objetos são construídos Duplicação de código
  8. Depois do container Centralização da construção dos objetos Não precisamos

    saber como construir os objetos complexos Menos de código duplicado Definição do container pode ser complexo
  9. Symfony DI The DependencyInjection component implements a PSR-11 compatible service

    container that allows you to standardize and centralize the way objects are constructed in your application. Extensível Performático Robusto
  10. Symfony DI (overview) Básico Arquivos de configuração (PHP, Yaml e

    XML) Carregando serviços automaticamente Injetando serviços automaticamente (autowiring) Abstrações Configurando serviços automaticamente (autoconfigure) Tagueamento de serviços (service tagging) Performance
  11. Sem necessidade de definir explicitamente todos os serviços Serviços podem

    ser manualmente definidos para alterar alguma configuração pontual Todas as classes dentro do namespace “App\” serão automaticamente definidas Exceto as classes dentro do diretório “src/Document” Ainda menos verbosidade Symfony DI (Service autoload)
  12. Symfony DI (autowiring) Serviços são automaticamente injetados Type-hint das dependências

    são utilizados como nome para localizar serviços Menos configuração manual do container Pode se tornar mais difícil quando utilizado abstrações (e.g interfaces)
  13. Symfony DI (Abstrações) Funciona sem nenhuma configuração especial para casos

    de uso simples (apenas uma implementação para interfaces) Auxilia nos princípios “LSP" e “DIP" do SOLID Considerado boas práticas de desenvolvimento
  14. Symfony DI (Abstrações) Deve-se definir uma implementação padrão através de

    alias pois o Symfony DI não pode “adivinhar" a instância a ser utilizada Todos os serviços irão utilizar a implementação padrão Serviços que dependem de outra implementação devem ser explicitamente configurados
  15. Symfony DI (Tagueamento) Informando explicitamente a lista de loggers Novos

    loggers (e.g LogstashLogger) devem ser adicionados manualmente na definição do serviço
  16. Symfony DI (Tagueamento) Adiciona automaticamente a tag “app.logger” nas implementações

    de “LoggerInterface" Novas implementações serão automaticamente injetadas no serviço “Registration" Menos verbosidade
  17. Symfony DI (Performance) Necessário compilar o container Custo de processamento

    na compilação Inviável para grandes aplicações e muitas requisições
  18. Symfony DI (Performance) Persiste o container em arquivo PHP Custo

    mínimo de processamento As funcionalidades do componente não impactam na performance