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

O que não precisei desaprender em POO

Rachel Curioso
November 27, 2020
320

O que não precisei desaprender em POO

Essa palestra fala um pouco sobre os princípios de SOLID, e como aproveitar em funcional.

Rachel Curioso

November 27, 2020
Tweet

Transcript

  1. O que não
    precisei
    desaprender
    de POO
    ou Um pouco sobre manutenção de código

    View full-size slide

  2. Oi, eu sou
    Rachel

    View full-size slide

  3. E trabalho na
    brainn.co (top)

    View full-size slide

  4. Essa palestra é
    um pouco da
    minha jornada
    em Funcional

    View full-size slide

  5. Comecei o
    livro da
    Sandi Metz
    *Practical Object-Oriented Design in Ruby

    View full-size slide

  6. Oportunidade
    de trabalhar
    com Elixir

    View full-size slide

  7. “Meu deus,
    gastei todo meu
    tempo nesse
    livro pra nada”

    View full-size slide

  8. Glossário
    Classe _ Conjunto de
    propriedades e
    funções. Representam
    um objeto;
    Subclasse _ Classe
    derivada de outra. Possui
    as mesmas propriedades
    e funções++;
    Herança _ Quando
    criamos uma subclasse a
    partir de uma classe.
    Subclasse A é uma
    herança da Classe B;
    Dependência _
    Classes/libs/módulo
    que são chamadas
    em outra
    classe/módulo;
    Interface _ É o
    conjunto de
    funções públicas;

    View full-size slide

  9. Apesar de não lidarmos
    mais com classes e
    herança, muito do
    conhecimento é
    aproveitável

    View full-size slide

  10. Quando os
    fundamentos
    apareceram foi
    para resolver um
    problema:

    View full-size slide

  11. Os códigos
    eram de difícil
    manutenção

    View full-size slide

  12. Independente do
    paradigma, códigos de
    difícil manutenção
    sempre vão existir

    View full-size slide

  13. E como identificar
    códigos de difícil
    manutenção?

    View full-size slide

  14. Sinais
    Rigidez _ Mudanças só são
    permitidas se forem críticas.
    Temos medo de mudar o
    código;
    Fragilidade _
    Qualquer pequeno fix
    quebra (muito) o código
    de formas imprevisíveis;
    Imobilidade _ Inabilidade de
    reutilização. É mais fácil fazer
    algo novo (e quase igual) do
    que reutilizar algo existente;
    Viscosidade _ Design »
    Gambiarras são mais fáceis do
    que fazer da forma correta;
    Environment » Deployar / testar
    / compilar é difícil e evitamos.

    View full-size slide

  15. E porque um
    projeto se
    estraga?

    View full-size slide

  16. Porque mudanças
    acontecem. Temos
    novas features
    *E nosso código não está preparado para elas.

    View full-size slide

  17. Um código preparado é
    reutilizável, modular e
    independente

    View full-size slide

  18. E foi pensando
    nisso que surgiu
    o SOLID

    View full-size slide

  19. SOLID = fundamentos
    para que seu código
    seja “manutenível”

    View full-size slide

  20. Parece que
    também
    precisamos disso
    em Funcional

    View full-size slide

  21. Talvez se entendermos
    o problema que cada
    conceito resolve,
    conseguimos ter um
    código melhor

    View full-size slide

  22. S. O. L . I . D.
    single
    responsibility
    principle
    S. O. L . I . D.

    View full-size slide

  23. Cada função,
    módulo, classe
    deve ter uma única
    responsabilidade

    View full-size slide

  24. Se precisamos usar um
    “e” ou “ou” na hora de
    explicar, provavelmente
    temos mais de uma
    responsabilidade

    View full-size slide

  25. E porque
    isso é um
    problema?

    View full-size slide

  26. _ Nosso código deveria ser reutilizável, cada
    função/módulo(/classe) deveria ser uma
    ferramenta;
    _ Código com mais de uma responsabilidade
    dificilmente é reutilizável;
    _ Se utilizarmos um código com muitas
    responsabilidades, uma alteração possui efeitos
    colaterais e fica frágil.

    View full-size slide

  27. Também
    podemos ter esse
    problema em
    funcional?

    View full-size slide

  28. _ Podemos ter código com muitas
    responsabilidades em funcional
    também;
    _ Sejam módulos, funções (e
    até contextos).

    View full-size slide

  29. Sempre que esbarrarmos
    em código com muita
    responsabilidade,
    devemos dividir
    *Inclusive essa é uma ótima forma de
    começar uma refatoração.

    View full-size slide

  30. S. O. L . I . D.
    open / closed
    principle
    S. O.

    View full-size slide

  31. Uma classe/módulo/função
    deve ser aberta para
    extensão e fechada para
    modificações

    View full-size slide

  32. Precisamos modificar
    o comportamento do
    código sem modificar
    o código (?)

    View full-size slide

  33. Em POO fazemos isso
    estendendo classes,
    geralmente por
    herança

    View full-size slide

  34. (Às vezes mudar
    código existente é
    necessário)

    View full-size slide

  35. E porque
    isso é um
    problema?

    View full-size slide

  36. Partindo do
    pressuposto que o
    código atual funciona,
    fazer uma adição tem
    menos chance de
    quebrar

    View full-size slide

  37. Também
    podemos ter esse
    problema em
    funcional?

    View full-size slide

  38. _ Também corremos o risco de quebrar
    tudo se modificarmos código
    existente;
    _ Precisamos escrever código passível
    de extensão (mas com parcimônia).

    View full-size slide

  39. Writing extensible
    functional code
    _ Renan Ranelli
    {youtube}

    View full-size slide

  40. S. O. L . I . D.
    liskov
    substitution
    principle
    S. O. L . I . D.

    View full-size slide

  41. Subclasses devem
    ser substituíveis
    pelas suas classes de
    origem

    View full-size slide

  42. Classe A
    Subclasse B
    Método X
    Método X

    View full-size slide

  43. E porque
    isso é um
    problema?

    View full-size slide

  44. _ Toda vez que for usado a função
    em comum, é preciso fazer um
    typecheck;
    _ Nosso código fica cheio de if pois
    o comportamento dele é meio
    imprevisível (= fragilidade).

    View full-size slide

  45. Também
    podemos ter esse
    problema em
    funcional?

    View full-size slide

  46. Esse problema em FP é menos
    comum que em OO, mas pode
    acontecer quando usamos
    protocolos. Precisamos nos
    atentar aos contratos

    View full-size slide

  47. S. O. L . I . D.
    interface
    segregation
    principle
    S. O. L . I . D.

    View full-size slide

  48. Criar várias
    interfaces é melhor
    que criar uma
    interface que faz
    tudo

    View full-size slide

  49. Isso não significa
    que vamos fazer
    muitas micro
    classes
    * Mas precisamos saber a hora
    de refatorar.

    View full-size slide

  50. E porque
    isso é um
    problema?

    View full-size slide

  51. _ Podemos usar uma classe que possui
    métodos e atributos que não fazem
    sentido pra nós;
    _ No final estamos lidando com
    classe com muita responsabilidade;
    _ Tantas outras classes dependem dela
    que mudanças vão ficando difíceis.

    View full-size slide

  52. Também
    podemos ter esse
    problema em
    funcional?

    View full-size slide

  53. A mesma coisa
    pode acontecer
    com um módulo
    * Abstrações nos ajudam a
    evitar esse problema

    View full-size slide

  54. S. O. L . I . D.
    dependency
    inversion
    principle
    S. O. L . I . D.

    View full-size slide

  55. Dependa de
    abstrações, e não
    de concretudes

    View full-size slide

  56. Acontece muito quando
    precisamos usar
    informações de uma
    classe em outra

    View full-size slide

  57. & quando
    adicionamos uma
    nova lib/gem/
    biblioteca externa

    View full-size slide

  58. E porque
    isso é um
    problema?

    View full-size slide

  59. _ Classes concretas têm mais risco de
    sofrerem modificações;
    _ Quando dependemos de classes voláteis,
    temos mais chance de quebrar o código, pois
    uma classe volátil possui mais chances de
    sofrer modificação;
    _ Uma modificação em classes com muitos
    dependentes pode causar problemas em efeito
    cascata.

    View full-size slide

  60. Também
    podemos ter esse
    problema em
    funcional?

    View full-size slide

  61. Também corremos
    o risco de ter
    dependências
    voláteis

    View full-size slide

  62. Precisamos
    saber como
    escolher nossas
    dependências

    View full-size slide

  63. Dependências
    Probl. de mudança
    Baixa Alta
    Muitas
    Poucas
    Zona
    Abstrata

    Zona
    Perigosa

    Zona
    Neutra

    Zona
    Neutra

    View full-size slide

  64. Fiz esse
    exercício
    usando SOLID

    View full-size slide

  65. A mesma coisa
    pode ser feita com
    design patterns

    View full-size slide

  66. Que problemas
    eles querem
    consertar?

    View full-size slide

  67. Esses
    problemas
    existem em
    FP?

    View full-size slide

  68. _ Independente do paradigma, patterns
    e princípios servem para tornar nosso
    código melhor;
    _ Todos nós queremos ter um código
    mais fácil de manter;
    _ Ter vindo de um background de POO
    me tornou uma programadora FP
    melhor.

    View full-size slide

  69. _ @_rchc
    _ rachc.dev

    View full-size slide