O que não precisei desaprender em POO

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

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