SOLID - Princípios para um melhor design de código

Palestra sobre SOLID realizada por mim e pelo Gabriel Sobrinho inicialmente apresentada no encontro do GURU-MG do dia 28 de julho de 2012 e aperfeiçoada para o 4º RS on Rails do dia 15 de setembro de 2012.

Transcript

1. SOLID princípios para um melhor design de código 1
2. QUE SOMOS NÓS? • @Sobrinho • Co-founder at Code5 • Co-founder at Nohup • Software Architect • gabrielsobrinho.com • @MarceloCajueiro • Co-founder at Code5 • Project Leader at Nohup • Software Engineer • marcelocajueiro.me 2
3. O QUE É SOLID? 3
4. ANTES, PRECISAMOS FALAR DE Orientação a Objeto 4
5. ORIENTAÇÃO A OBJETO Quais suas vantagens? 5
6. OO MAL FEITO É O MESMO QUE PROCEDURAL 6
7. Introduzido pelo Uncle Bob (Robert Martin) em 2000 SOLID 7
8. S.O.L.I.D. • Single Responsibility Principle (SRP) • Open/Closed Principle (OCP) • Liskov Substitution Principle (LSP) • Interface Segregation Principle (ISP) • Dependency Inversion Principle (DIP) 8
9. SOLID • Inspirado no subaproveitamento da OO • Com foco principal no acoplamento/dependências • Aplicado inicialmente apenas em linguagens estáticas 9
10. SINGLE RESPONSIBILITY PRINCIPLE • Uma entidade (classe, método, módulo) deve ter uma única responsabilidade • Responsabilidade pode ser definida como “razão para mudar” 10
11. Código “ruim” SRP 11
12. Aplicando o SRP SRP 12
13. OPEN-CLOSED PRINCIPLE (NEM SEMPRE É A MELHOR OPÇÃO) • Uma classe deve estar aberta para extensão mas fechada para modificação • Alterar a classe apenas para arrumar bugs • Novas funcionalidades são adicionadas em heranças 13
14. OPEN-CLOSED PRINCIPLE (CONVENÇÃO DIFERENTE) • Uma classe deve manter a sua interface (API pública) • A implementação pode ser alterada livremente 14
15. Implementação mudou mas a interface (API pública) permaneceu OCP 15
16. LISKOV SUBSTITUTION PRINCIPLE • Deve ser possível substituir uma classe por suas classes derivadas em qualquer ponto do código • As propriedades do programa não devem ser alteradas para isso acontecer 16
17. Pode-se usar qualquer uma das heranças e não irá quebrar a classe que depende da interface (API pública) de Animal LSP 17
18. INTERFACE SEGREGATION PRINCIPLE • Classes não devem ser obrigadas a depender de interfaces (API pública) que elas não utilizam • Deve-se usar interfaces (API pública) concisas, com apenas o que é realmente é usado • O SRP resolve este problema 18
19. Classe bala de prata ISP 19
20. Aplicando o SRP, se aplica o ISP ISP 20
21. DEPENDENCY INVERSION PRINCIPLE • Módulos de alto nível não devem depender de módulos de baixo nível, ambos devem depender de abstrações (interface/ API pública) • Abstrações não devem depender de detalhes, detalhes devem depender de abstrações 21
22. Código sem DIP (fortemente acoplado) DIP 22
23. E se eu quiser fazer cache ao invés de salvar no banco de dados? DIP 23
24. Isso parece bom? DIP 24
25. Bye bye acoplamento DIP 25
26. S.O.L.I.D. • Single Responsibility Principle (SRP) • Open/Closed Principle (OCP) • Liskov Substitution Principle (LSP) • Interface Segregation Principle (ISP) • Dependency Inversion Principle (DIP) 26
27. REFERÊNCIAS • Edmilson Filho: http://www.slideshare.net/EdmilsonFilho2/princpios-solid-12117410 • *Gregory Brown*: http://blog.rubybestpractices.com/posts/gregory/055-issue-23-solid-design.html • *Jim Weirich*: http://confreaks.com/videos/185-rubyconf2009-solid-ruby • Lucas Hungaro: http://www.slideshare.net/lucashungaro/solid-atravs-de-bdd-um-guia-prtico-para-rubistas • *Sandi Metz*: http://confreaks.com/videos/240-goruco2009-solid-object-oriented-design • Uncle Bob: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod • Vinicius Quaiato: http://viniciusquaiato.com/blog/palestra-orientacao-a-objetos-e-principios-solid-slides-e-demos/ • Wikipedia: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) 27
28. code5.io 28
29. DÚVIDAS? 29