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

Hacking Evening - Liskov Substitution Principle

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

Elaine Naomi

September 18, 2018
Tweet

More Decks by Elaine Naomi

Other Decks in Programming

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!