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.

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.

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!