princípios solid
TRANSCRIPT
Princípios SOLID
André MinelliAgosto/2017
O que é software de qualidade?
Software de Qualidade:
Alta Coesão
e
Baixo Acoplamento
Sintomas da Baixa Qualidade:
Sintomas da Baixa Qualidade:
• Rigidez
Sintomas da Baixa Qualidade :
• Rigidez
• Fragilidade
Sintomas da Baixa Qualidade :
• Rigidez
• Fragilidade
• Imobilidade
Sintomas da Baixa Qualidade :
• Rigidez
• Fragilidade
• Imobilidade
Then what???
S.O.L.I.D.
to the rescue!
Lembre-se!
Princípio ≠ Regra
Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
Single Responsibility Principle (SRP)
“Uma classe deve ter somente umarazão para mudar”
Responsabilidade = O que a classe faz?
Responsabilidade Única = Alta Coesão!
Quanto mais for feito, maior será a chance de alterar!
Quanto mais for alterado, maior será a chance de introduzir bugs!
Benefícios:
Benefícios:
• Reuso
Benefícios:
• Reuso
• Clareza
Benefícios:
• Reuso
• Clareza
• Nomeação
Benefícios:
• Reuso
• Clareza
• Nomeação
• Leitura Fácil
Críticas:
Críticas:
• ‘Granularidade’ da Responsabilidade
Críticas:
• ‘Granularidade’ da Responsabilidade
• Explosão de classes
DEMO
Open-Closed Principle (OCP)
“Módulos devem ser abertos para extensão e fechados para modificação”
• Aberto para extensão
Comportamento pode ser estendido
• Fechado para modificação
Estender não significa alterar o códigooriginal diretamente
Técnicas:
Técnicas:
• Parametrização
Técnicas:
• Parametrização
• Herança
Técnicas:
• Parametrização
• Herança
• Eventos
Técnicas:
• Parametrização
• Herança
• Eventos
• Métodos de extensão
Técnicas:
• Parametrização
• Herança
• Eventos
• Métodos de extensão
• Composição
Benefícios:
Benefícios:
• Bugs apenas em código novo
Benefícios:
• Bugs apenas em código novo
• Baixo acoplamento
Críticas:
• Exige planejamento antecipado
DEMO
Liskov Substitution Principle (LSP)
“Tipos derivados devem podersubstituir seu tipo base”
Código não deve precisar saber que o tipo atual é um sub-tipo específico
Violação Mais Comum:
if (obj is <SubType>)
O comportamento deve serindistinguível entre tipo base e
qualquer sub-tipo
Violações Comuns em Sub-tipos:
• Lançar novas exceções
Violações Comuns em Sub-tipos:
• Lançar novas exceções
• Pré-condições mais restritivas
Violações Comuns em Sub-tipos:
• Lançar novas exceções
• Pré-condições mais restritivas
• Pós-condições menos restritivas
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
Soluções Comuns:
Soluções Comuns:
• Documentação
Soluções Comuns:
• Documentação
• Utilizar Code Contracts For .NET
Soluções Comuns:
• Documentação
• Utilizar Code Contracts For .NET
• Criar hierarquias separadas
Soluções Comuns:
• Documentação
• Utilizar Code Contracts For .NET
• Criar hierarquias separadas
• Aplicar “Tell, Don´t Ask” Principle
DEMO
Interface Segregation Principle (ISP)
“Clientes não devem ser forçados a depender de interfaces que eles não
usam”
Não crie interfaces grandes(com vários métodos)!
Interface menor => Alta Coesão
Benefícios:
Benefícios:
• Facilidade para implementar
Benefícios:
• Facilidade para implementar
• Mais fácil de usar
DEMO
ASP.NET MembershipProvider
Na maioria das vezes bastaria:
bool ValidateUser(string username, string password)
Versão Mais Recente:
ASP.NET Identity
Dependency Inversion Principle (DIP)
“Dependa de abstrações, não dependade implementações”
Infraestrutura
Aplicação
Infraestrutura
AplicaçãoAbstração da Infraestrutura
Técnicas:
Técnicas:
• Strategy pattern
Técnicas:
• Strategy pattern
• Adapter pattern
Técnicas:
• Strategy pattern
• Adapter pattern
• Dependency Injection
Benefícios:
Benefícios:
• Bugs apenas em código novo
• Baixo acoplamento
Benefícios:
• Bugs apenas em código novo
• Baixo acoplamento
• Testabilidade
Benefícios:
• Bugs apenas em código novo
• Baixo acoplamento
• Testabilidade
• Extensibilidade
Críticas:
• Menos controle sobre detalhes
Críticas:
• Menos controle sobre detalhes
• “Navegação” é mais difícil
DEMO
Lembre-se!
Princípio ≠ Regra
“Programar não é apenasescrever código, assim como
cozinhar não é apenas misturaringredientes”
Referências:• http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOo
d• http://www.infoq.com/presentations/design-principles-
code-structures• http://www.slideshare.net/Hitheshh/solid-31661700• http://channel9.msdn.com/Events/TechEd/NorthAmerica/2
014/DEV-B315• http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id
=92• https://docs.microsoft.com/en-
us/dotnet/framework/debug-trace-profile/code-contracts• http://simpleinjector.readthedocs.io/en/latest/Interception
Extensions.html