O documento discute os cinco Princípios SOLID de projeto de software, que visam melhorar a qualidade e manutenibilidade do código. São eles: Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle e Dependency Inversion Principle. Cada princípio é explicado com seus benefícios e técnicas para implementação, como herança, injeção de dependência e padrões de projeto.

1. Princípios SOLID
André Minelli
Julho/2014

2. O que é software de qualidade?

3. Software de Qualidade:
Alta Coesão
e
Baixo Acoplamento

4. Sintomas da Baixa Qualidade:

5. Sintomas da Baixa Qualidade:
• Rigidez

6. Sintomas da Baixa Qualidade :
• Rigidez
• Fragilidade

7. Sintomas da Baixa Qualidade :
• Rigidez
• Fragilidade
• Imobilidade

8. Sintomas da Baixa Qualidade :
• Rigidez
• Fragilidade
• Imobilidade

9. Then what???

10. S.O.L.I.D.
To The Rescue!

11. Lembre-se!
Princípio ≠ Regra

12. Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

13. Single Responsibility Principle (SRP)
“Uma classe deve ter somente uma
razão para mudar”

14. Responsabilidade = O que a classe faz?
Responsabilidade Única = Alta Coesão!

15. Quanto mais for feito, maior será a
chance de alterar!
Quanto mais for alterado, maior será a
chance de introduzir bugs!

16. Benefícios:

17. Benefícios:
• Reuso

18. Benefícios:
• Reuso
• Clareza

19. Benefícios:
• Reuso
• Clareza
• Nomeação

20. Benefícios:
• Reuso
• Clareza
• Nomeação
• Leitura Fácil

21. Críticas:

22. Críticas:
• ‘Granularidade’ da Responsabilidade

23. Críticas:
• ‘Granularidade’ da Responsabilidade
• Explosão de classes

24. DEMO

25. Open-Closed Principle (OCP)
“Módulos devem ser abertos para
extensão e fechados para modificação”

26. • Aberto para extensão
Comportamento pode ser estendido
• Fechado para modificação
Estender não significa alterar o código
original diretamente

27. Técnicas:

28. Técnicas:
• Parametrização

29. Técnicas:
• Parametrização
• Herança

30. Técnicas:
• Parametrização
• Herança
• Eventos

31. Técnicas:
• Parametrização
• Herança
• Eventos
• Métodos de extensão

32. Técnicas:
• Parametrização
• Herança
• Eventos
• Métodos de extensão
• Composição

33. Benefícios:

34. Benefícios:
• Bugs apenas em código novo

35. Benefícios:
• Bugs apenas em código novo
• Baixo acoplamento

36. Críticas:
• Exige planejamento antecipado

37. DEMO

38. Liskov Substitution Principle (LSP)
“Tipos derivados devem poder
substituir seu tipo base”

39. Código não deve precisar saber que o
tipo atual é um sub-tipo específico

40. Violação Mais Comum:
if (obj is <SubType>)

41. O comportamento deve ser
indistinguível entre tipo base e
qualquer sub-tipo

42. Violações Comuns em Sub-tipos:
• Lançar novas exceções

43. Violações Comuns em Sub-tipos:
• Lançar novas exceções
• Pré-condições mais restritivas

44. Violações Comuns em Sub-tipos:
• Lançar novas exceções
• Pré-condições mais restritivas
• Pós-condições menos restritivas

45. Violações Comuns em Sub-tipos:
• Lançar novas exceções
• Pré-condições mais restritivas
• Pós-condições menos restritivas
• Invariantes menos restritivos

46. Soluções Comuns:

47. Soluções Comuns:
• Documentação

48. Soluções Comuns:
• Documentação
• Utilizar Code Contracts For .NET

49. Soluções Comuns:
• Documentação
• Utilizar Code Contracts For .NET
• Criar hierarquias separadas

50. Soluções Comuns:
• Documentação
• Utilizar Code Contracts For .NET
• Criar hierarquias separadas
• Aplicar “Tell, Don´t Ask” Principle

51. DEMO

52. Interface Segregation Principle (ISP)
“Clientes não devem ser forçados a
depender de interfaces que eles não
usam”

53. Não crie interfaces grandes
(com vários métodos)!
Interface menor => Alta Coesão

54. Benefícios:

55. Benefícios:
• Facilidade para implementar

56. Benefícios:
• Facilidade para implementar
• Mais fácil de usar

57. DEMO

58. ASP.NET MembershipProvider

59. Na maioria das vezes bastaria:
bool ValidateUser(string username, string password)

60. Versão Mais Recente:
ASP.NET Identity

61. Dependency Inversion Principle (DIP)
“Dependa de abstrações, não dependa
de implementações”

62. Técnicas:

63. Técnicas:
• Strategy pattern

64. Técnicas:
• Strategy pattern
• Adapter pattern

65. Técnicas:
• Strategy pattern
• Adapter pattern
• Dependency Injection

66. Benefícios:

67. Benefícios:
• Bugs apenas em código novo
• Baixo acoplamento

68. Benefícios:
• Bugs apenas em código novo
• Baixo acoplamento
• Testabilidade

69. Benefícios:
• Bugs apenas em código novo
• Baixo acoplamento
• Testabilidade
• Extensibilidade

70. Críticas:
• Menos controle sobre detalhes

71. Críticas:
• Menos controle sobre detalhes
• “Navegação” é mais difícil

72. DEMO

73. Lembre-se!
Princípio ≠ Regra

74. “Programar não é apenas
escrever código, assim como
cozinhar não é apenas misturar
ingredientes”

75. Referências:
• http://www.objectmentor.com/resources/articles/Principle
s_and_Patterns.pdf
• http://www.infoq.com/presentations/design-principles-
code-structures
• http://www.slideshare.net/Hitheshh/solid-31661700
• www.craigberntson.com/docs/SOLID.pptx
• http://channel9.msdn.com/Events/TechEd/NorthAmerica/2
014/DEV-B315
• http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id
=92
• http://research.microsoft.com/en-us/projects/contracts/
• https://simpleinjector.codeplex.com/wikipage?title=Advanc
ed-scenarios#Interception