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

O que não precisei desaprender em POO

E4decad72f078fd0070fdb67ff086043?s=47 Rachel Curioso
November 27, 2020
290

O que não precisei desaprender em POO

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

E4decad72f078fd0070fdb67ff086043?s=128

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
  2. Oi, eu sou Rachel

  3. E trabalho na brainn.co (top)

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

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

    Ruby
  6. Oportunidade de trabalhar com Elixir

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

  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;
  9. Apesar de não lidarmos mais com classes e herança, muito

    do conhecimento é aproveitável
  10. Quando os fundamentos apareceram foi para resolver um problema:

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

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

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

  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.
  15. E porque um projeto se estraga?

  16. Porque mudanças acontecem. Temos novas features *E nosso código não

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

  18. E foi pensando nisso que surgiu o SOLID

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

  20. Parece que também precisamos disso em Funcional

  21. Talvez se entendermos o problema que cada conceito resolve, conseguimos

    ter um código melhor
  22. S. O. L . I . D. single responsibility principle

    S. O. L . I . D.
  23. Cada função, módulo, classe deve ter uma única responsabilidade

  24. Se precisamos usar um “e” ou “ou” na hora de

    explicar, provavelmente temos mais de uma responsabilidade
  25. E porque isso é um problema?

  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.
  27. Também podemos ter esse problema em funcional?

  28. _ Podemos ter código com muitas responsabilidades em funcional também;

    _ Sejam módulos, funções (e até contextos).
  29. Sempre que esbarrarmos em código com muita responsabilidade, devemos dividir

    *Inclusive essa é uma ótima forma de começar uma refatoração.
  30. S. O. L . I . D. open / closed

    principle S. O.
  31. Uma classe/módulo/função deve ser aberta para extensão e fechada para

    modificações
  32. Precisamos modificar o comportamento do código sem modificar o código

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

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

  35. E porque isso é um problema?

  36. Partindo do pressuposto que o código atual funciona, fazer uma

    adição tem menos chance de quebrar
  37. Também podemos ter esse problema em funcional?

  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).
  39. Writing extensible functional code _ Renan Ranelli {youtube}

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

    S. O. L . I . D.
  41. Subclasses devem ser substituíveis pelas suas classes de origem

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

  43. E porque isso é um problema?

  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).
  45. Também podemos ter esse problema em funcional?

  46. Esse problema em FP é menos comum que em OO,

    mas pode acontecer quando usamos protocolos. Precisamos nos atentar aos contratos
  47. S. O. L . I . D. interface segregation principle

    S. O. L . I . D.
  48. Criar várias interfaces é melhor que criar uma interface que

    faz tudo
  49. Isso não significa que vamos fazer muitas micro classes *

    Mas precisamos saber a hora de refatorar.
  50. E porque isso é um problema?

  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.
  52. Também podemos ter esse problema em funcional?

  53. A mesma coisa pode acontecer com um módulo * Abstrações

    nos ajudam a evitar esse problema
  54. S. O. L . I . D. dependency inversion principle

    S. O. L . I . D.
  55. Dependa de abstrações, e não de concretudes

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

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

  58. E porque isso é um problema?

  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.
  60. Também podemos ter esse problema em funcional?

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

  62. Precisamos saber como escolher nossas dependências

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

    Zona Perigosa Zona Neutra Zona Neutra
  64. Fiz esse exercício usando SOLID

  65. A mesma coisa pode ser feita com design patterns

  66. Que problemas eles querem consertar?

  67. Esses problemas existem em FP?

  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.
  69. Obrigada

  70. _ @_rchc _ rachc.dev