Princípios SOLID

25
S.O.L.I.D. Princípios de Design para Programação Orientada a Objetos

description

Apresentação de SOLID para a equipe de desenvolvimento da WebCasters

Transcript of Princípios SOLID

Page 1: Princípios SOLID

S.O.L.I.D.Princípios de Design para Programação Orientada

a Objetos

Page 2: Princípios SOLID

O Código Apodrece

Inevitável Exemplo de correção de bug

Acoplamento Mudança em uma linha de código gera

mudanças em outras tantas Nós temos que nos munir de armas

contra o apodrecimento do código SOLID é uma das armas

Page 3: Princípios SOLID

S.O.L.I.D.

Desenvolvimento de Sistemas não é um jogo Jenga

Page 4: Princípios SOLID

Princípios

Single Responsibility Principle Princípio de Responsabilidade Única

Open Closed Principle Princípio Aberto Fechado

Liskov Substitution Principle Princípio da Substituição de Liskov

Interface Segregation Principle Princípio da Segregação de Interface

Dependency Inversion Principle Princípio da Inversão de Dependência

Page 5: Princípios SOLID

Vantagens

Fácil de manter, adaptar e ajustar às constantes mudanças exigidas pelos clientes

Fácil de entender e testar Menor esforço para manutenções Melhor reaproveitamento de código

Page 6: Princípios SOLID

Princípio de Responsabilidade Única

Todo objeto deve ter uma única responsabilidade, e todos os seus serviços devem estar rigorosamente alinhados com aquela responsabilidade.

Page 7: Princípios SOLID

Princípio de Responsabilidade Única

Sintomas quando o princípio não é seguido: Quantas vezes abrimos um código e

simplesmente não temos a mínima ideia do que ele está fazendo?

Quantas variáveis espalhadas, aparentemente sem sentido?

Quantos cálculos mentais temos que fazer para descobrir se vai entrar naquele IF?

E quando a barra de rolagem parece não ter fim?

Page 8: Princípios SOLID

Princípio de Responsabilidade Única

Uma classe ou método deve ter uma e apenas uma razão para mudar

Quebrando o princípio: TransmissaoRepositorio

Seguindo o princípio: TransmissaoRepositorio ConversorTransmissao ControladorDiscoRigido ControladorEmail

Page 9: Princípios SOLID

Princípio Aberto Fechado

Cirurgia de peito aberto não é necessário ao colocar um casaco.

Page 10: Princípios SOLID

Princípio Aberto Fechado

Sintomas quando o princípio não é seguido: Adicionar novas regras requer mudança

sempre no mesmo pedaço de código Cada mudança pode introduzir bugs e

requer novos testes Mudar um pedaço de código cria mudança

em cascata em várias classes. If-ElseIf-Else encadeados Switch-Case

Page 11: Princípios SOLID

Princípio Aberto Fechado

Aberto para extensão Novo comportamento pode ser adicionado

no futuro Fechado para modificação

Não há necessidade de modificar o código Como adicionar novo comportamento

sem mudar o código? Depender de abstrações: Interfaces ou

Classes Abstratas

Page 12: Princípios SOLID

Princípio Aberto Fechado

Quebrando o princípio: Carrinho

Seguindo o princípio: Carrinho CalculadorPreco IRegraPreco RegraPrecoEspecial RegraPrecoPorGrama RegraPrecoCada

Page 13: Princípios SOLID

Substituição de Liskov

Caso se pareça um pato e grasne como um pato mas precise de baterias, você provavelmente possui a abstração errada.

Page 14: Princípios SOLID

Substituição de Liskov

Os subtipos devem ser substituíveis pelos seus tipos base.

Sintoma quando o princípio não é seguido: Usar o operador “is” ou “typeof” em

condições if-else ou switch

Page 15: Princípios SOLID

Substituição de Liskov

Quebrando o princípio: Retangulo Quadrado

Seguindo o princípio: Forma Retangulo Quadrado

Quadrado só é um retângulo no mundo real. Essa abstração “é-um” nesse caso não é válida.

Page 16: Princípios SOLID

Segregação de Interface

Você quer que eu plugue isso onde?

Page 17: Princípios SOLID

Segregação de Interface

Clientes não devem ser forçados a dependerem de métodos que eles não usam

Sintomas quando o princípio não é seguido: Interfaces com vários métodos, “gordas” Quebra o princípio de Responsabilidade Única Implementar uma interface “gorda” e nos

métodos que não quer implementar lançar uma exceção Por exemplo: método não suportado Ou throw new NotImplementedException()

Page 18: Princípios SOLID

Segregação de Interface

Quebrando o princípio Contato ControladorEmail Discador

Seguindo o princípio: IDiscavel IEmail Contato ControladorEmail Discador

Page 19: Princípios SOLID

Inversão de Dependência

Você soldaria uma lâmpada diretamente no fio de eletricidade na parede?

Page 20: Princípios SOLID

Inversão de Dependência

Um módulo de alto nível não deve depender de outros de baixo nível Baixo nível: acesso a banco, arquivos, WebServices Alto nível: regras e entidades de negócio, interação

com usuário Módulos de alto nível devem utilizar um

mecanismo para obter os dados de baixo nível, mas não depender dos detalhes desse mecanismo

UI depender do módulo de persistência, por exemplo banco de dados Se a persistência mudar para arquivo Xml, toda a UI

terá que ser reescrita

Page 21: Princípios SOLID

Inversão de Dependência

Sintomas: Dentro de um módulo/classe/método

instanciar uma classe explicitamente usando o operador “new”

Possuir referência do projeto de acesso a dados no projeto de UI

O ideal é sempre depender de abstrações: Interfaces ou classes abstratas

Page 22: Princípios SOLID

Inversão de Dependência

TransmissaoRepositorio

ControladorEmailConversorTransm

issao

Page 23: Princípios SOLID

Inversão de Dependência

TransmissaoRepositorio

IControladorEmail

IConversorTransmissao

ConversorTransmissao

ControladorEmail

Page 24: Princípios SOLID

Inversão de Dependência

Aplicando o princípio nos exemplos: SingleResponsibility OpenClosed

Page 25: Princípios SOLID

Referências

Software Practices, Pluralsight Principles of Object Oriented Design Design Patterns

Clean Code A Handbook of Agile Software Craftsmanship, Robert C. Martin

Agile Principles, Patterns, and Practices in C#, Robert C. Martin