SlideShare uma empresa Scribd logo
1 de 23
Single Responsibility
      Principle




André Faria Gomes @andrefaria
Os princípios de Orientação à Objetos são apenas
guidelines. Você precisa pesar os prós e contras e o
   impacto na entrega, no custo e na manutenção.
1   Uma classe deve possuir uma, apenas
     uma, razão para ser modificada, ou
       seja deva possuir uma única
           responsabilidade.
Cada
 responsabilidade
 deve ser uma classe
 separada porque cada
responsabilidade é 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ócio.




*Active Record é utilizado com muito
   sucesso em muitos aplicativos.
    Lembre-se é só um guideline.
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.
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 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.
É melhor, separarmos essas diferentes funcionalidades em
classes distintas, de forma que cada classes possa ser alterar
        de forma independente umas da outras.
class CalculadoraDePagamento {
  public Dinheiro calcularPagamento() {...}
}



class RelatorioDeHoras {
  public String reportarHoras() {...}
}


class FuncionarioDao {
  public void salvar() {...}
}
1        SRP in Ruby

                                                     2




http://butunclebob.com/ArticleS.UncleBob.SrpInRuby
http://www.objectmentor.com/resources/articles/srp.pdf

 http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod




Referências
Obrigado
    @andrefaria

Mais conteúdo relacionado

Semelhante a SOLID - Princípio da Responsabilidade Única

Katálysis - Webshow - Automação Laboratorial V
Katálysis - Webshow - Automação Laboratorial VKatálysis - Webshow - Automação Laboratorial V
Katálysis - Webshow - Automação Laboratorial V
Katálysis Científica
 
Sap Inside Track Sao Paulo 09 Classes De Negócio Em Abap Orientado A Objetos
Sap Inside Track Sao Paulo 09 Classes De Negócio Em Abap Orientado A ObjetosSap Inside Track Sao Paulo 09 Classes De Negócio Em Abap Orientado A Objetos
Sap Inside Track Sao Paulo 09 Classes De Negócio Em Abap Orientado A Objetos
Marcelo Ramos
 
J Boss Rules Mgjug V2
J Boss Rules Mgjug V2J Boss Rules Mgjug V2
J Boss Rules Mgjug V2
Breno Barros
 

Semelhante a SOLID - Princípio da Responsabilidade Única (20)

DB2 Express-C
DB2 Express-CDB2 Express-C
DB2 Express-C
 
Katálysis - Webshow - Automação Laboratorial V
Katálysis - Webshow - Automação Laboratorial VKatálysis - Webshow - Automação Laboratorial V
Katálysis - Webshow - Automação Laboratorial V
 
Encapsulamento em Orientação a Objetos
Encapsulamento em Orientação a ObjetosEncapsulamento em Orientação a Objetos
Encapsulamento em Orientação a Objetos
 
Refactoring Databases
Refactoring DatabasesRefactoring Databases
Refactoring Databases
 
Guia Passo a Passo_ Como Criar uma Conta de Serviç... - ServiceNow Community.pdf
Guia Passo a Passo_ Como Criar uma Conta de Serviç... - ServiceNow Community.pdfGuia Passo a Passo_ Como Criar uma Conta de Serviç... - ServiceNow Community.pdf
Guia Passo a Passo_ Como Criar uma Conta de Serviç... - ServiceNow Community.pdf
 
Mvc delphi
Mvc delphiMvc delphi
Mvc delphi
 
JAVA REFLETCION
JAVA REFLETCIONJAVA REFLETCION
JAVA REFLETCION
 
OLAP, BI, EIS
OLAP, BI, EISOLAP, BI, EIS
OLAP, BI, EIS
 
Artigo Padrões J2EE: Um exemplo de uso
Artigo Padrões J2EE: Um exemplo de usoArtigo Padrões J2EE: Um exemplo de uso
Artigo Padrões J2EE: Um exemplo de uso
 
Arquitetura de sistemas web
Arquitetura de sistemas webArquitetura de sistemas web
Arquitetura de sistemas web
 
Sap Inside Track Sao Paulo 09 Classes De Negócio Em Abap Orientado A Objetos
Sap Inside Track Sao Paulo 09 Classes De Negócio Em Abap Orientado A ObjetosSap Inside Track Sao Paulo 09 Classes De Negócio Em Abap Orientado A Objetos
Sap Inside Track Sao Paulo 09 Classes De Negócio Em Abap Orientado A Objetos
 
Design de aplicações orientadas a objeto
Design de aplicações orientadas a objetoDesign de aplicações orientadas a objeto
Design de aplicações orientadas a objeto
 
TDC2018SP | Trilha Ruby - Design de aplicacoes orientadas a objeto: uma visao...
TDC2018SP | Trilha Ruby - Design de aplicacoes orientadas a objeto: uma visao...TDC2018SP | Trilha Ruby - Design de aplicacoes orientadas a objeto: uma visao...
TDC2018SP | Trilha Ruby - Design de aplicacoes orientadas a objeto: uma visao...
 
J Boss Rules Mgjug V2
J Boss Rules Mgjug V2J Boss Rules Mgjug V2
J Boss Rules Mgjug V2
 
SAP Inside Track - Belo Horizonte
SAP Inside Track - Belo HorizonteSAP Inside Track - Belo Horizonte
SAP Inside Track - Belo Horizonte
 
requisitos de software.pptx
requisitos de software.pptxrequisitos de software.pptx
requisitos de software.pptx
 
Implementing Product Line Variabilities
Implementing Product Line VariabilitiesImplementing Product Line Variabilities
Implementing Product Line Variabilities
 
MDA-gerenciamento
MDA-gerenciamentoMDA-gerenciamento
MDA-gerenciamento
 
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
 
Pgbr2013
Pgbr2013Pgbr2013
Pgbr2013
 

Mais de André Faria Gomes

Mais de André Faria Gomes (20)

Meetup Escale - Gestão para Equipes de Alta Performance
Meetup Escale - Gestão para Equipes de Alta PerformanceMeetup Escale - Gestão para Equipes de Alta Performance
Meetup Escale - Gestão para Equipes de Alta Performance
 
Protagonistas da inovação - Como criar e gerir os negócios do futuro
Protagonistas da inovação - Como criar e gerir os negócios do futuroProtagonistas da inovação - Como criar e gerir os negócios do futuro
Protagonistas da inovação - Como criar e gerir os negócios do futuro
 
A Mobilidade como Propulsor da Transformação Digital
A Mobilidade como Propulsor da Transformação DigitalA Mobilidade como Propulsor da Transformação Digital
A Mobilidade como Propulsor da Transformação Digital
 
Além da Agilidade 2019 - KickOff Wow
Além da Agilidade 2019 - KickOff WowAlém da Agilidade 2019 - KickOff Wow
Além da Agilidade 2019 - KickOff Wow
 
Modern systems architectures: Uber, Lyft, Cabify
Modern systems architectures: Uber, Lyft, CabifyModern systems architectures: Uber, Lyft, Cabify
Modern systems architectures: Uber, Lyft, Cabify
 
Breaking the monolith
Breaking the monolithBreaking the monolith
Breaking the monolith
 
Agilidade - APAS
Agilidade - APASAgilidade - APAS
Agilidade - APAS
 
Principles and Radical Transparency - Lessons Learned from Ray Dalio
Principles and Radical Transparency - Lessons Learned from Ray DalioPrinciples and Radical Transparency - Lessons Learned from Ray Dalio
Principles and Radical Transparency - Lessons Learned from Ray Dalio
 
Bluesoft @ AWS re:Invent 2017 + AWS 101
Bluesoft @ AWS re:Invent 2017 + AWS 101Bluesoft @ AWS re:Invent 2017 + AWS 101
Bluesoft @ AWS re:Invent 2017 + AWS 101
 
Boas Práticas da Rede Supermercadista Wegmans
Boas Práticas da Rede Supermercadista WegmansBoas Práticas da Rede Supermercadista Wegmans
Boas Práticas da Rede Supermercadista Wegmans
 
Boas Práticas para Supermercadistas inspiradas no Whole Foods, Sprouts Marke...
Boas Práticas para Supermercadistas inspiradas no Whole Foods, Sprouts Marke...Boas Práticas para Supermercadistas inspiradas no Whole Foods, Sprouts Marke...
Boas Práticas para Supermercadistas inspiradas no Whole Foods, Sprouts Marke...
 
Change management - Kotter’s eight-step model
Change management - Kotter’s eight-step model Change management - Kotter’s eight-step model
Change management - Kotter’s eight-step model
 
Palestra na Uninove sobre Agilidade
Palestra na Uninove sobre AgilidadePalestra na Uninove sobre Agilidade
Palestra na Uninove sobre Agilidade
 
Pensando Rápido e Devagar
Pensando Rápido e DevagarPensando Rápido e Devagar
Pensando Rápido e Devagar
 
What happened to Google Reader?
What happened to Google Reader?What happened to Google Reader?
What happened to Google Reader?
 
Gestão Ágil com Management 3.0
Gestão Ágil com Management 3.0Gestão Ágil com Management 3.0
Gestão Ágil com Management 3.0
 
Lições aprendidas em 10 anos de agilidade
Lições aprendidas em 10 anos de agilidadeLições aprendidas em 10 anos de agilidade
Lições aprendidas em 10 anos de agilidade
 
Os 7 hábitos das pessoas altamente eficazes
Os 7 hábitos das pessoas altamente eficazesOs 7 hábitos das pessoas altamente eficazes
Os 7 hábitos das pessoas altamente eficazes
 
Objetividade: A Virtude Esquecida
Objetividade: A Virtude EsquecidaObjetividade: A Virtude Esquecida
Objetividade: A Virtude Esquecida
 
Bematech IFRS
Bematech IFRSBematech IFRS
Bematech IFRS
 

Último

Assessement Boas Praticas em Kubernetes.pdf
Assessement Boas Praticas em Kubernetes.pdfAssessement Boas Praticas em Kubernetes.pdf
Assessement Boas Praticas em Kubernetes.pdf
Natalia Granato
 

Último (6)

ATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docx
ATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docxATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docx
ATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docx
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 
ATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docx
ATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docxATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docx
ATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docx
 
Boas práticas de programação com Object Calisthenics
Boas práticas de programação com Object CalisthenicsBoas práticas de programação com Object Calisthenics
Boas práticas de programação com Object Calisthenics
 
Assessement Boas Praticas em Kubernetes.pdf
Assessement Boas Praticas em Kubernetes.pdfAssessement Boas Praticas em Kubernetes.pdf
Assessement Boas Praticas em Kubernetes.pdf
 
Padrões de Projeto: Proxy e Command com exemplo
Padrões de Projeto: Proxy e Command com exemploPadrões de Projeto: Proxy e Command com exemplo
Padrões de Projeto: Proxy e Command com exemplo
 

SOLID - Princípio da Responsabilidade Única

  • 1. Single Responsibility Principle André Faria Gomes @andrefaria
  • 2. Os princípios de Orientação à Objetos são apenas guidelines. Você precisa pesar os prós e contras e o impacto na entrega, no custo e na manutenção.
  • 3. 1 Uma classe deve possuir uma, apenas uma, razão para ser modificada, ou seja deva possuir uma única responsabilidade.
  • 4. Cada responsabilidade deve ser uma classe separada porque cada responsabilidade é eixo para a mudança
  • 5. it does it all, does it well, and does it only
  • 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() {...} }
  • 9. Pergunte-se O que esta classe faz?
  • 10. Calcula o Salário e Reporta Horas e Salva
  • 11. Calcula o Salário e Reporta Horas e Salva
  • 12. Calcula o Salário e Reporta Horas e Salva
  • 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
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 23. Obrigado @andrefaria