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