Hacking Evening - Liskov Substitution Principle
0 gostou65 visualizações
O documento discute o Princípio da Substituição de Liskov (LSP), que estabelece que subclasses devem ser substituíveis por suas superclasses sem alterar as propriedades desejadas do programa. O LSP é importante para manter a correção do comportamento quando se usa herança e polimorfismo. Classes derivadas devem respeitar os contratos definidos pelas classes base para não violar o princípio.
Hacking Evening - Liskov Substitution Principle
- 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??
- 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
- 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!