O que não precisei desaprender em POO

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Oi, eu sou Rachel

Slide 3

Slide 3 text

E trabalho na brainn.co (top)

Slide 4

Slide 4 text

Essa palestra é um pouco da minha jornada em Funcional

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Oportunidade de trabalhar com Elixir

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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;

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Quando os fundamentos apareceram foi para resolver um problema:

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Sinais Rigidez _ Mudanças só são permitidas se forem críticas. Temos medo de mudar o código; Fragilidade _ Qualquer pequeno ﬁx 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.

Slide 15

Slide 15 text

E porque um projeto se estraga?

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

E foi pensando nisso que surgiu o SOLID

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Parece que também precisamos disso em Funcional

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

E porque isso é um problema?

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Também podemos ter esse problema em funcional?

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

E porque isso é um problema?

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Também podemos ter esse problema em funcional?

Slide 38

Slide 38 text

_ 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).

Slide 39

Slide 39 text

Writing extensible functional code _ Renan Ranelli {youtube}

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Subclasses devem ser substituíveis pelas suas classes de origem

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

E porque isso é um problema?

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Também podemos ter esse problema em funcional?

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

E porque isso é um problema?

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Também podemos ter esse problema em funcional?

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

& quando adicionamos uma nova lib/gem/ biblioteca externa

Slide 58

Slide 58 text

E porque isso é um problema?

Slide 59

Slide 59 text

_ 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 modiﬁcação; _ Uma modiﬁcação em classes com muitos dependentes pode causar problemas em efeito cascata.

Slide 60

Slide 60 text

Também podemos ter esse problema em funcional?

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Precisamos saber como escolher nossas dependências

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

Fiz esse exercício usando SOLID

Slide 65

Slide 65 text

A mesma coisa pode ser feita com design patterns

Slide 66

Slide 66 text

Que problemas eles querem consertar?

Slide 67

Slide 67 text

Esses problemas existem em FP?

Slide 68

Slide 68 text

_ 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.