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.647 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
0 comentários
6 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
4.647
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1.473
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
6
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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

×