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.
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. Se uma regra de negócio muda e faz com uma
determinada classe mude, então uma mudança no
esquema do banco de dados, na GUI, no formato do
relatório, ou em qualquer outra área do sistema não
deve fazer com essa mesma classe mude.
8. class Funcionario
{
public Dinheiro calcularPagamento() {...}
public void salvar() {...}
public String reportarHoras() {...}
}
13. Não é bom ter que modificar a classe
Funcionario toda vez que alguém decidir
mudar o formato do relatório de
horas, 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. É melhor, separarmos essas diferentes funcionalidades em
classes distintas, de forma que cada classes possa ser alterar
de forma independente umas da outras.
15. class CalculadoraDePagamento {
public Dinheiro calcularPagamento() {...}
}
class RelatorioDeHoras {
public String reportarHoras() {...}
}
class FuncionarioDao {
public void salvar() {...}
}
16. 1 SRP in Ruby
2
http://butunclebob.com/ArticleS.UncleBob.SrpInRuby