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

Hacking Evening - Liskov Substitution Principle

583e920a7e9238a1c21e923025f8f641?s=47 Elaine Naomi
September 18, 2018

Hacking Evening - Liskov Substitution Principle

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

583e920a7e9238a1c21e923025f8f641?s=128

Elaine Naomi

September 18, 2018
Tweet

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

  12. None
  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.
  27. 1987

  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!