Design de aplicações orientadas a objeto

Modelamos aplicações Ruby como um conjunto de objetos interagindo entre si para resolver um problema.

Quando propomos uma solução, ela geralmente é validada dentro de um escopo específico.

Mas mudanças sempre acontecem: no código, nas regras de negócio, na vida, no universo e em tudo mais.

Com essas mudanças, será que uma solução inicialmente proposta continua sendo válida? Se não for, o código implementado está preparado para evoluir e agregar novos comportamentos de maneira saudável?

Nesta talk, vamos analisar princípios e padrões de design de aplicações orientadas a objeto e como podemos aplicá-los no dia a dia a fim de tornar nosso código mais flexível e com maior qualidade.

Transcript

1. design de aplicações orientadas a objeto uma visão rubista
2. olar
3. Elaine Naomi Watanabe Desenvolvedora de Software (Plataformatec) Mestre em Ciência da Computação (USP) github.com/elainenaomi twitter.com/elaine_nw
4. http://careers.plataformatec.com.br
5. quais são os conceitos básicos de orientação a objeto como identificar problemas na nossa base de código como melhorar o design do nosso código o que vamos ver?
6. orientação a objeto uma versão super resumida
7. Objeto abstração de uma parte do domínio/problema estados/valores específicos para seus atributos Classe template/gabarito para definição de objetos um conjunto de atributos (características) e métodos (comportamentos)
8. Herança herdar atributos/métodos comuns de uma classe base (ou superclasse) e adicionar novos atributos/métodos Polimorfismo ter uma interface única de acesso para diferentes classes/objetos Composição combinar objetos simples de modo a ter objetos mais complexos
9. objetos + mensagens = app
10. no mundo do Ruby...
11. $ gem install rails
12. $ gem install rails + Rails way
13. View Model Controller apresentação intermediador dados + lógica de negócio
14. e se o projeto começa a crescer?
16. + Funcionalidades
17. + Funcionalidades + Modificações
18. + Funcionalidades + Modificações + Bugs
19. Tamanho da base de código Tempo para deploy
21. como reconhecer os sintomas?
23. Muitas regras de negócio nos controllers Métodos muito longos Classes muito grandes
24. Excesso de callbacks (controllers/models) Dificuldade para escrever testes Classes de difícil manutenção
25. Ctrl + F / ⌘ + F para qualquer alteração Arquivos constantemente alterados
26. e agora, como faz?
27. DRY don't repeat yourself
28. Helpers Presenters
29. Single Table Inheritance Polymorphic Association
30. Concerns (cuidado!)
31. Service Objects
32. Uso de Plain Old Ruby Object (PORO) Casos de uso Regras de negócio explícitas
33. class ReserveBookService attr_reader :user, :book, :notification_service def initialize(user, book, notification_service) @user = user @book = book @notification_service = notification_service end def confirm! user.books << book notification_service.reservation_completed(user, book) end end
34. SOLID
35. Single Responsibility Principle
36. O que a minha classe faz? Indicativo de problemas: usar "e" ou "ou" na explicação
37. Métodos relacionados? Uma única razão para mudar? Alterações com efeitos previsíveis?
38. class BooksUser < ApplicationRecord belongs_to: :book belongs_to: :user after_commit :send_notification_reservation_completed def send_notification_reservation_completed NotificationService.reservation_completed(user, book) end end
39. class BooksUser < ApplicationRecord belongs_to: :book belongs_to: :user after_commit :send_notification_reservation_completed def send_notification_reservation_completed NotificationService.reservation_completed(user, book) end end
40. Uma classe de persistência não deveria saber sobre notificações a um usuário, por ex. Que tal um Service Object para isso?
41. class ReserveBookService attr_reader :user, :book, :notification_service def initialize(user, book, notification_service) @user = user @book = book @notification_service = notification_service end def confirm! user.books << book notification_service.reservation_completed(user, book) end end
42. Open/Closed Principle
43. Adicionar nova regra = modificar uma ou mais classes? Se sim, é um indicativo de problema
44. Aberto para extensão, fechado para modificação Defina interfaces/super classes Reduza o acoplamento
45. class FinancialReport def generate(account, file_format) case file_format when :csv file = FormatCSV.generate_file(account.transactions) when :xml file = XML.parse_list(account.transactions) end Mailer.send(account.email, file) end end
46. class FinancialReport def generate(account, file_format) case file_format when :csv file = FormatCSV.generate_file(account.transactions) when :xml file = XML.parse_list(account.transactions) when :pdf file = PDFGenerator.create(account.transactions) end Mailer.send(account.email, file) end end edição
47. class FinancialReport def generate(account, file_format) case file_format when :csv file = FormatCSV.generate_file(account.transactions) when :xml file = XML.parse_list(account.transactions) when :pdf file = PDFGenerator.create(account.transactions) end Mailer.send(account.email, file) end end
48. class FinancialReport def generate(account, file_creator) file = file_creator.create(account.transactions) Mailer.send(account.email, file) end end
49. class FileCreator def create(items) raise NotImplementedError end end contrato
50. class FileCreatorXML < FileCreator def create(items) XML.parse(items) end end class FileCreatorCSV < FileCreator def create(items) FormatCSV.generate_file(items) end end
51. class FileCreatorPDF < FileCreator def create(items) PDFGenerator.generate(items) end end adição
52. class FinancialReport def generate(account, file_creator) file = file_creator.create(account.transactions) Mailer.send(account.email, file) end end FinancialReport.new.generate(account, FileCreatorPDF.new)
53. Liskov Substitution Principle
54. Design by contract respeitar os contratos definidos pela classe base
55. 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
56. 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
57. class PayrollAccount < CheckingAccount class OperationNotAllowed < StandardError; end # ... def compute_bonus raise OperationNotAllowed end end
58. CheckingAccount.all.each do |account| account.compute_bonus end
59. CheckingAccount.all.each do |account| begin account.compute_bonus rescue PayrollAccount::OperationNotAllowed false end end
60. CheckingAccount.all.each do |account| begin account.compute_bonus rescue PayrollAccount::OperationNotAllowed false end end contrato quebrado
61. 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
62. 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
63. Deveriam ser classes diferentes
64. Interface Segregation Principle
65. Uma classe derivada não deveria ser obrigada a implementar métodos que ela não usa
66. class CoffeeMachine def brew_coffee # brew coffee logic end def fill_coffee_beans # fill coffee beans end end
67. class Person attr_reader :coffee_machine def initialize @coffee_machine = CoffeeMachine.new End def quero_cafe coffee_machine.brew_coffee end end
68. class Staff attr_reader :coffee_machine def initialize @coffee_machine = CoffeeMachine.new end def fill_coffee_beans coffee_machine.fill_coffee_beans end end
69. Várias interfaces específicas é melhor do que uma interface generalizada
70. class CoffeeMachineUserInterface def brew_coffee # brew coffee logic end end class CoffeeMachineServiceInterface def fill_coffee_beans # fill coffee beans end end
71. class CoffeeMachineUserInterface def brew_coffee # brew coffee logic end end class CoffeeMachineServiceInterface def fill_coffee_beans # fill coffee beans end end
72. class Person attr_reader :coffee_machine def initialize @coffee_machine = CoffeeMachineUserInterface.new end def quero_cafe coffee_machine.brew_coffee end end `
73. class Person attr_reader :coffee_machine def initialize @coffee_machine = CoffeeMachineUserInterface.new end def quero_cafe coffee_machine.brew_coffee end end ` `
74. class Staff attr_reader :coffee_machine def initialize @coffee_machine = CoffeeMachineServiceInterface.new end def fill_coffee_beans coffee_machine.fill_coffee_beans end end
75. class Staff attr_reader :coffee_machine def initialize @coffee_machine = CoffeeMachineServiceInterface.new end def fill_coffee_beans coffee_machine.fill_coffee_beans end end
76. Dependency Inversion Principle
77. Dependa de abstrações, não de implementações
78. class FinancialReport def generate(account, file_creator) file = file_creator.create(account.transactions) Mailer.send(account.email, file) end end
79. class FileCreatorCSV < FileCreator def create(items) FormatCSV.generate_file(items) end End FinancialReport.new.generate(account, FileCreatorCSV.new)
80. class FileCreatorCSV < FileCreator def create(items) FormatCSV.generate_file(items) NewCSVGenerator.parse(items, header: false) end End FinancialReport.new.generate(account, FileCreatorCSV.new)
81. Tell, don't ask
82. Não exponha a regra de negócio Não deixe quem usa o objeto tomar decisões por ele com base no seu estado Confie no seu objeto!
83. Encapsule estados Crie uma interface pública mínima
84. class Subscription def charge(user) if user.has_credit_card? user.charge(total) else false end end end
85. class Subscription def charge(user) if user.has_credit_card? user.charge(total) else false end end end
86. class User def charge(total) if has_credit_card? payment_gateway.charge(credit_card, total) true else false end end end
87. class User def charge(total) if has_credit_card? payment_gateway.charge(credit_card, total) true else false end end end
88. class Subscription def charge(user) user.charge(total) end end
89. TL;DR;
90. TL;DR: Alta coesão Baixo acoplamento Encapsulamento
92. vamos refatorar tudo?
94. esses conceitos nos ajudam a criar aplicações mais flexíveis
95. converse com seu time
96. analisem juntos os trade-offs
97. cuidado com big design up front
98. e não esqueçam:
99. codar é um processo de comunicação
101. Mais sobre design? Padrões de projeto TDD, DDD
102. minhas referências
105. Refactoring rails apps Flavia Fortes http://bit.ly/rubyconfbr-refactoring https://speakerdeck.com/flaviafortes
107. RAILS GIRLS SP 17 e 18 de agosto railsgirls.com/saopaulo
108. obrigada speakerdeck.com/elainenaomi