Your SlideShare is downloading. ×
0
• Desenvolvedor.• Capixaba residente no  Rio de Janeiro.• Pouco mais de 1 ano de PU.• Time de App Services.• Flamengo.• ww...
• Fazer software NÃO é fácil.• Fazer software bem projetado para  ser mantido é ainda mais complicado.
• Orientação a Objeto mal inplementada é igual  ao paradigma procedural.
• Não é necessário ser nenhum gênio.Mas...• Como profissionais temos  obrigação de estudar  constantemente.
• Design pattern• Princípios de design
S   Single responsibilityO   Open/closedL   Liskov substitutionI   Interface segregationD   Dependency inversion
• Robert C. Martin (“Uncle Bob”)• Início dos anos 2000• Conjunto de boas práticasCuriosidade: O termo SOLID não foi invent...
Princípio da Responsabilidade Única“Nunca deve haver mais do que uma razão para           uma classe de mudar”
- “Classe, o que você faz?”    (a pergunta pode ser feita a método também)
Mudanças vão acontecer• Menos responsabilidade, menos dificuldade• Baixo acoplamento• Facilidade de leitura do código
Princípio do Aberto/Fechado  “Entidades de software (classes, módulos,funções, etc) devem ser abertas para extensão,      ...
• Evolução sem medo• Não criar bugs em código que funciona
• Strategy Pattern• Decorator Pattern
Princípio da Substituição de Liskov“Deve ser possível substituir uma classe base        por suas classes derivadas”       ...
Quadrado herda de retângulo?
Princípio de Segregação de Interface“Clientes não devem ser forçados a depender de        interfaces que eles não vão usar”
OBS.: Espero que pelo menos não                       tenha sido no Internet Explorer throw new NotImplementedException();
• Facilitar a implementação de interfaces.• Ter interfaces mais específicas (SRP, certo? ).
Princípio de Inversão de Dependência “Módulos de alto nível não deve depender demódulos de baixo nível. Ambos devem depend...
• Sistema desacoplado e flexível.• Código testável.• Facilidade de mudança.
• Princípios e padrões são itens de boas  práticas.• Avaliar a situação antes de aplicar.• Prós e contras.
• Wikipedia: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)• Blog Vinícius Quaiato: http://viniciusquaiato.co...
Princípios SOLID
Princípios SOLID
Princípios SOLID
Princípios SOLID
Princípios SOLID
Princípios SOLID
Princípios SOLID
Princípios SOLID
Princípios SOLID
Princípios SOLID
Upcoming SlideShare
Loading in...5
×

Princípios SOLID

1,352

Published on

Apresentação para equipe de engenharia do Peixe Urbano sobre "SOLID Principles".

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,352
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
42
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Rever
  • Transcript of "Princípios SOLID"

    1. 1. • Desenvolvedor.• Capixaba residente no Rio de Janeiro.• Pouco mais de 1 ano de PU.• Time de App Services.• Flamengo.• www.flamengorj.com.br
    2. 2. • Fazer software NÃO é fácil.• Fazer software bem projetado para ser mantido é ainda mais complicado.
    3. 3. • Orientação a Objeto mal inplementada é igual ao paradigma procedural.
    4. 4. • Não é necessário ser nenhum gênio.Mas...• Como profissionais temos obrigação de estudar constantemente.
    5. 5. • Design pattern• Princípios de design
    6. 6. S Single responsibilityO Open/closedL Liskov substitutionI Interface segregationD Dependency inversion
    7. 7. • Robert C. Martin (“Uncle Bob”)• Início dos anos 2000• Conjunto de boas práticasCuriosidade: O termo SOLID não foi inventadopor Uncle Bob.
    8. 8. Princípio da Responsabilidade Única“Nunca deve haver mais do que uma razão para uma classe de mudar”
    9. 9. - “Classe, o que você faz?” (a pergunta pode ser feita a método também)
    10. 10. Mudanças vão acontecer• Menos responsabilidade, menos dificuldade• Baixo acoplamento• Facilidade de leitura do código
    11. 11. Princípio do Aberto/Fechado “Entidades de software (classes, módulos,funções, etc) devem ser abertas para extensão, mas fechadas para modificação” Bertrand Meyer
    12. 12. • Evolução sem medo• Não criar bugs em código que funciona
    13. 13. • Strategy Pattern• Decorator Pattern
    14. 14. Princípio da Substituição de Liskov“Deve ser possível substituir uma classe base por suas classes derivadas” Barbara Liskov e Jeannette Wing
    15. 15. Quadrado herda de retângulo?
    16. 16. Princípio de Segregação de Interface“Clientes não devem ser forçados a depender de interfaces que eles não vão usar”
    17. 17. OBS.: Espero que pelo menos não tenha sido no Internet Explorer throw new NotImplementedException();
    18. 18. • Facilitar a implementação de interfaces.• Ter interfaces mais específicas (SRP, certo? ).
    19. 19. Princípio de Inversão de Dependência “Módulos de alto nível não deve depender demódulos de baixo nível. Ambos devem depender de abstrações.” “Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.”
    20. 20. • Sistema desacoplado e flexível.• Código testável.• Facilidade de mudança.
    21. 21. • Princípios e padrões são itens de boas práticas.• Avaliar a situação antes de aplicar.• Prós e contras.
    22. 22. • Wikipedia: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)• Blog Vinícius Quaiato: http://viniciusquaiato.com/• Blog Lambda3: http://blog.lambda3.com.br• .Net Architects Podcast: http://podcast.dotnetarchitects.net
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×