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 Slide

  2. Oi, eu sou
    Rachel

    View Slide

  3. E trabalho na
    brainn.co (top)

    View Slide

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

    View Slide

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

    View Slide

  6. Oportunidade
    de trabalhar
    com Elixir

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

  15. E porque um
    projeto se
    estraga?

    View Slide

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

    View Slide

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

    View Slide

  18. E foi pensando
    nisso que surgiu
    o SOLID

    View Slide

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

    View Slide

  20. Parece que
    também
    precisamos disso
    em Funcional

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  25. E porque
    isso é um
    problema?

    View 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 Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. E porque
    isso é um
    problema?

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  43. E porque
    isso é um
    problema?

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  50. E porque
    isso é um
    problema?

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  58. E porque
    isso é um
    problema?

    View 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 Slide

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

    View Slide

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

    View Slide

  62. Precisamos
    saber como
    escolher nossas
    dependências

    View Slide

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

    Zona
    Perigosa

    Zona
    Neutra

    Zona
    Neutra

    View Slide

  64. Fiz esse
    exercício
    usando SOLID

    View Slide

  65. A mesma coisa
    pode ser feita com
    design patterns

    View Slide

  66. Que problemas
    eles querem
    consertar?

    View Slide

  67. Esses
    problemas
    existem em
    FP?

    View 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 Slide


  69. Obrigada

    View Slide

  70. _ @_rchc
    _ rachc.dev

    View Slide