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. DEPRECATED PHOTO Elaine Naomi Watanabe Desenvolvedora de Software (Plataformatec) Mestre

    em Ciência da Computação (USP) github.com/elainenaomi twitter.com/elaine_nw
  2. 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.
  3. 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.
  4. 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
  5. Tipos Abstratos de Dados Conjunto de comportamentos/operações Estrutura de dados

    específica (atributos) Como representar elementos do domínio de negócio
  6. 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
  7. 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"
  8. 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.
  9. Herança: herança de comportamentos de uma super classe Polimorfismo: definição

    de uma interface única para acessar tipos diferentes de objetos
  10. 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)
  11. 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
  12. 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
  13. class PayrollAccount < CheckingAccount class OperationNotAllowed < StandardError; end #

    ... def compute_bonus raise OperationNotAllowed end end
  14. 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
  15. 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
  16. class Rectangle attr_reader :width, :height def initialize(width, height) @width =

    width @height = height end def area width * height end end
  17. 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