O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
Single Responsibility      PrincipleAndré Faria Gomes @andrefaria
Os princípios de Orientação à Objetos são apenasguidelines. Você precisa pesar os prós e contras e o   impacto na entrega,...
1   Uma classe deve possuir uma, apenas     uma, razão para ser modificada, ou       seja deva possuir uma única           ...
Cada responsabilidade deve ser uma classe separada porque cadaresponsabilidade é eixo    para a mudança
it does it all, does it well, and does it only
Um exemplo popular que “viola” o princípio é o ActiveRecord*, que  mistura persistência com regras de               negóci...
Se uma regra de negócio muda e faz com uma determinada classe mude, então uma mudança noesquema do banco de dados, na GUI,...
class Funcionario{  public Dinheiro calcularPagamento() {...}  public void salvar() {...}  public String reportarHoras() {...
Pergunte-se              O que esta classe faz?
Calcula o Salário e Reporta Horas e Salva
Calcula o Salário e Reporta Horas e Salva
Calcula o Salário e Reporta Horas e Salva
Não é bom ter que modificar a classe Funcionario toda vez que alguém decidirmudar o formato do relatório dehoras, ou toda v...
É melhor, separarmos essas diferentes funcionalidades emclasses distintas, de forma que cada classes possa ser alterar    ...
class CalculadoraDePagamento {  public Dinheiro calcularPagamento() {...}}class RelatorioDeHoras {  public String reportar...
1        SRP in Ruby                                                     2http://butunclebob.com/ArticleS.UncleBob.SrpInRuby
http://www.objectmentor.com/resources/articles/srp.pdf http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOodReferências
Obrigado    @andrefaria
SOLID - Princípio da Responsabilidade Única
SOLID - Princípio da Responsabilidade Única
SOLID - Princípio da Responsabilidade Única
SOLID - Princípio da Responsabilidade Única
SOLID - Princípio da Responsabilidade Única
Próximos SlideShares
Carregando em…5
×

SOLID - Princípio da Responsabilidade Única

4.725 visualizações

Publicada em

Nesta apresentação é abordado o Princípio SRP (Single Responsibility Principle - Princípio de Única Responsabilidade) do Grupo de Princípios SOLID de boas práticas de Design de Software Orientado à Objetos.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

SOLID - Princípio da Responsabilidade Única

  1. 1. Single Responsibility PrincipleAndré Faria Gomes @andrefaria
  2. 2. Os princípios de Orientação à Objetos são apenasguidelines. Você precisa pesar os prós e contras e o impacto na entrega, no custo e na manutenção.
  3. 3. 1 Uma classe deve possuir uma, apenas uma, razão para ser modificada, ou seja deva possuir uma única responsabilidade.
  4. 4. Cada responsabilidade deve ser uma classe separada porque cadaresponsabilidade é eixo para a mudança
  5. 5. it does it all, does it well, and does it only
  6. 6. Um exemplo popular que “viola” o princípio é o ActiveRecord*, que mistura persistência com regras de negócio.*Active Record é utilizado com muito sucesso em muitos aplicativos. Lembre-se é só um guideline.
  7. 7. Se uma regra de negócio muda e faz com uma determinada classe mude, então uma mudança noesquema do banco de dados, na GUI, no formato dorelatório, ou em qualquer outra área do sistema não deve fazer com essa mesma classe mude.
  8. 8. class Funcionario{ public Dinheiro calcularPagamento() {...} public void salvar() {...} public String reportarHoras() {...}}
  9. 9. Pergunte-se O que esta classe faz?
  10. 10. Calcula o Salário e Reporta Horas e Salva
  11. 11. Calcula o Salário e Reporta Horas e Salva
  12. 12. Calcula o Salário e Reporta Horas e Salva
  13. 13. Não é bom ter que modificar a classe Funcionario toda vez que alguém decidirmudar o formato do relatório dehoras, ou toda vez que o DBA fizer uma mudança no schema do banco de dados, ou toda vez que as regras de cálculo de pagamento forem alteradas.
  14. 14. É melhor, separarmos essas diferentes funcionalidades emclasses distintas, de forma que cada classes possa ser alterar de forma independente umas da outras.
  15. 15. class CalculadoraDePagamento { public Dinheiro calcularPagamento() {...}}class RelatorioDeHoras { public String reportarHoras() {...}}class FuncionarioDao { public void salvar() {...}}
  16. 16. 1 SRP in Ruby 2http://butunclebob.com/ArticleS.UncleBob.SrpInRuby
  17. 17. http://www.objectmentor.com/resources/articles/srp.pdf http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOodReferências
  18. 18. Obrigado @andrefaria

×