Hacking Evening - Liskov Substitution Principle

Apresentação do Princípio de Substituição de Liskov no Hacking Evening da Plataformatec

Transcript

1. Liskov Substitution Principle Hacking Evening - SOLID Principles
2. hello
3. DEPRECATED PHOTO Elaine Naomi Watanabe Desenvolvedora de Software (Plataformatec) Mestre em Ciência da Computação (USP) github.com/elainenaomi twitter.com/elaine_nw
4. Recapitulando... Estamos em uma série de talks sobre design de código envolvendo o conceito SOLID
5. Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
6. Single Responsibility Principle Alta coesão de classes Isolamento de responsabilidades Encapsulamento
7. Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
8. Open/Closed Principle Redução do acoplamento Definição de interfaces/abstrações Polimorfismo Reúso
9. Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
10. Liskov??
11. https://bit.ly/2NRiznt
13. Spoiler: vai ter um pouco de teoria Aguentem, por favor <3
14. Barbara Liskov Institute Professor from MIT The 2008 Turing Award winner liskov at csail.mit.edu
15. Liskov Substitution Principle (1987) Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T.
16. Eita!
17. Liskov Substitution Principle (1987) Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T.
18. Liskov Substitution Principle (1987) Teoria dos Tipos (Type Theory)
19. Teoria dos Tipos Como representar caracteres, números inteiros e de ponto flutuante, booleanos no nível do processador? Abstrações! E não pensar em bits e bytes! E cada tipo tem suas restrições/comportamentos
20. Tipos Abstratos de Dados Conjunto de comportamentos/operações Estrutura de dados específica (atributos) Como representar elementos do domínio de negócio
21. Tipos Abstratos de Dados Conjunto de comportamentos/operações Estrutura de dados específica (atributos) Como representar elementos do domínio de negócio CLASSES
22. Liskov Substitution Principle (1987) Let φ(x) be a property provable about objects x of type T. CLASSE
23. Liskov Substitution Principle (1987) Let φ(x) be a property provable about objects x of type T. COMPORTAMENTO
24. Liskov Substitution Principle (1987) Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T. "SUBCLASSES"
25. Liskov Substitution Principle (1987) Classes vs Subclasses Interfaces vs Implementações
26. Liskov Substitution Principle (1987) Traduzindo: Preciso garantir que se eu substituir um objeto de uma classe por um outro objeto de uma subclasse dessa classe, as propriedades que definem o objeto-pai precisam continuar funcionando.
28. Herança: herança de comportamentos de uma super classe Polimorfismo: definição de uma interface única para acessar tipos diferentes de objetos
29. ALERTA! Cuidado com interpretações equivocadas sobre LSP: Se uma subclasse altera o comportamento da superclasse, nem sempre é uma violação desse princípio Podemos e devemos usar o polimorfismo (mas com sabedoria)
30. Design by contract respeitar os contratos definidos pelo super tipo
31. Design by contract respeitar os contratos definidos pela classe base
32. Pré-condições: dados de entrada classes derivadas só podem ser mais permissivas Pós-condições: dados de saída classes derivadas só podem ser mais restritivas Não podemos criar comportamentos inesperados ou incorretos! O comportamento da super classe precisa ser mantido
33. class CheckingAccount # ... def deposit(value) raise InvalidValueError if value <= 0 self.balance = self.balance + value end def compute_bonus self.balance = self.balance * 1.01 end end
34. class PayrollAccount < CheckingAccount class OperationNotAllowed < StandardError; end # ... def compute_bonus raise OperationNotAllowed end end
35. CheckingAccount.all.each do |account| account.compute_bonus end
36. CheckingAccount.all.each do |account| begin account.compute_bonus rescue PayrollAccount::OperationNotAllowed false end end
37. CheckingAccount.all.each do |account| begin account.compute_bonus rescue PayrollAccount::OperationNotAllowed false end end contrato quebrado
38. class PayrollAccount < CheckingAccount # ... def deposit(value) raise InvalidValueError if value <= 100 self.balance = self.balance + value end def compute_bonus self.balance = self.balance * 1.01 end end
39. class PayrollAccount < CheckingAccount # ... def deposit(value) raise InvalidValueError if value <= 100 self.balance = self.balance + value end def compute_bonus self.balance = self.balance * 1.01 end end contrato quebrado
40. Deveriam ser classes diferentes
41. Exemplo clássico: Retângulo x Quadrado
42. class Rectangle attr_reader :width, :height def initialize(width, height) @width = width @height = height end def area width * height end end
43. class Square < Rectangle attr_reader :width, :height def initialize(width) @width = width @height = width end end contrato quebrado
44. O que a gente precisa lembrar sobre esse princípio? Interfaces/Abstração de comportamentos Polimorfismo Design by contract Nem tudo que parece herança deveria ser uma herança
45. Até a próxima!