Diferença entre o Princípio da Responsabilidade Única e a Separação de Preocupações

Question

Qual é a diferença entre o Princípio da Responsabilidade Única e a Separação de Preocupações?

Answer 1

Princípio de responsabilidade única (SRP)- Dê a cada classe apenas um motivo para mudar; e "Razão para mudar" == "Responsabilidade". No exemplo: a classe de fatura não tem a responsabilidade de se imprimir.

Separação de preocupações (desde 1974). Preocupação == recurso do sistema. Cuidando de cada uma das preocupações: para cada uma das preocupações, outras preocupações são irrelevantes. Ocultar a implementação do comportamento.

A partir de aqui.

Answer 2

Separação de preocupação versus princípio de responsabilidade única (SOC vs SRP)

Do artigo vinculado:

Separação de preocupações (SOC) - é o processo de quebrar um programa de computador em recursos distintos que se sobrepõem à funcionalidade o mínimo possível. Uma preocupação é qualquer interesse ou foco em um programa. Normalmente, as preocupações são sinônimos de recursos ou comportamentos.http://en.wikipedia.org/wiki/separation_of_concerns

Princípio de responsabilidade única (SRP) - Todo objeto deve ter uma única responsabilidade e que todos os seus serviços devem estar alinhados por essa responsabilidade. Em algum nível, a coesão é considerada sinônimo de SRP.http://en.wikipedia.org/wiki/Single_RESPONSIBILY_PRINCIPLE

Answer 3

A responsabilidade única afirma que um objeto é responsável por uma única unidade de trabalho.

A separação de preocupações afirma que os aplicativos devem ser divididos em módulos cujas funcionalidades se sobrepõem o mínimo possível.

Resultados finais semelhantes ... aplicações ligeiramente diferentes.

Answer 4

Na minha opinião, o princípio de responsabilidade única é uma das ferramentas/idiomas para alcançar a separação de preocupações.

Answer 5

O princípio único de responsabilidade e a separação de preocupações são realmente a mesma coisa.

Claro que você pode ficar atolado em uma discussão acadêmica tentando provocar algum tipo de diferença entre os dois, mas por quê? Para todos os efeitos, eles descrevem a mesma coisa. O maior problema é que as pessoas ficam tão envolvidas em querer saber exatamente o que é uma "preocupação" e "responsabilidade", que talvez sintam falta da importante idéia por trás do SRP e do SOC.

Essa idéia é simplesmente dividir sua base de código em peças isoladas pouco acopladas. Isso permite que vários desenvolvedores trabalhem em diferentes partes sem se afetar, também permite que um único desenvolvedor modifique uma parte isolada sem quebrar outra.

Isso é aplicado no nível do módulo, por exemplo, MVC é um padrão arquitetônico que promove SRP e SOC. A base de código é dividida em modelos, vistas e controladores isolados. Dessa forma, a modificação de uma visão pode ser feita independentemente de um modelo. Dois dois não estão horrivelmente entrelaçados.

Em um nível mais baixo, isso também deve ser aplicado às classes. Em vez de colocar dezenas de métodos em uma única classe, divida o código em vários. Pelas mesmas razões.

Também mesmo em um nível de método, divida grandes métodos em métodos menores.

Em princípio. O SRP é um princípio, não uma regra, então você não precisa (leia: não pode/não deveria) segui -lo religiosamente ao extremo. Isso não significa ir muito longe e ter apenas um método de sete linhas em cada classe, por exemplo. Significa apenas um princípio geral de dividir o código em peças isoladas. O ponto é que ele levará a uma base de código melhor e um software mais estável.

Answer 6

Separação de preocupações (SOC). Divida seu aplicativo em recursos distintos com o mínimo de sobreposição da funcionalidade possível. (Microsoft).

“Preocupação” = “Recurso distinto” = “Seção Distinta”

"Preocupação" funciona em níveis altos e baixos

Princípio de responsabilidade únicaafirma que todo módulo ou classe deve ter responsabilidade em uma única parte da funcionalidade fornecida pelo software e que a responsabilidade deve ser totalmente encapsulada pela classe. Todos os seus serviços devem estar alinhados por essa responsabilidade. (Definição da Wikipedia)

“Responsabilidade” = “Razão para mudar” mudar o que? “Uma única parte da funcionalidade fornecida pelo software” = Unidade Básica

Conclusão

• Princípio de responsabilidade única funciona em unidades básicas -> funciona em baixo nível

• A separação de preocupações funciona em níveis altos e baixos

• SRP e SOC trabalham juntos para separação de preocupações. Eles são
  exatamente o mesmo em nível baixo

Answer 7

A separação de preocupações é um processo; O princípio de responsabilidade única é uma filosofia de design / arquitetura. Eles não estão completamente descontados, mas servem a propósitos diferentes.

Answer 8

Como nenhuma das respostas anteriores cita Robert Martin, que criou o Princípio de responsabilidade única, Acho que é necessária uma resposta mais autorizada aqui.

A inspiração de Martin para o SRP foi extraída de David Parnas, Edsger Dijkstra (que cunhou o termo Separação de preocupações) e Larry Constantine (que cunhou os termos Acoplamento e Coesão). Martin consolidou suas idéias no SRP.

Outra redação do princípio de responsabilidade única é:

Reúna as coisas que mudam pelas mesmas razões. Separe as coisas que mudam por diferentes razões.

Se você pensar sobre isso, perceberá que essa é apenas outra maneira de definir coesão e acoplamento. Queremos aumentar a coesão entre as coisas que mudam pelas mesmas razões, e queremos diminuir o acoplamento entre as coisas que mudam por diferentes razões.

No entanto, ao pensar sobre esse princípio, lembre -se de que as razões para a mudança são pessoas. Isso é pessoas quem solicita mudanças. E você não quer confundir essas pessoas, ou a si mesmo, misturando o código com o qual muitas pessoas diferentes se preocupam por diferentes razões.

Para a pergunta original, a pequena diferença entre o SRP e o SOC é que Martin refinou o termo preocupações referir-se a pessoas.

Answer 9

Semelhante, mas: o SOC está relacionado a preocupações: para dividir um problema complexo em várias preocupações, o SRP é ter apenas uma responsabilidade.

Answer 10

SRP e SOC trabalham em diferentes níveis de abstração. O objetivo é em ambos os casos reduzir o acoplamento e fortalecer a coesão. Enquanto o SRP funciona mais em um nível de objeto, o SOC também pode funcionar na implementação do nível de função. Uma função pode ser implementada por um objeto, mas também por vários objetos. Portanto, o acoplamento e a coesão de ambos os princípios podem diferir.

Answer 11

Tentei fazer uma comparação entre a Separação de Preocupações (SoC) e o Princípio de Responsabilidade Única (SRP).

Diferenças

• O SRP está no nível da classe, mas o SoC está em cada programa de computador, abstração...ou às vezes em nível arquitetônico.

• O SRP trata da qualidade de (como e não do quê) dividir seu domínio em classes coesas que têm apenas uma responsabilidade (um motivo para mudar).Por outro lado, SoC é um princípio de design para separar um contexto em seções distintas, de modo que cada seção trate de uma preocupação separada (o que e não como), já que existem muitas ferramentas (por exemplo, classes, funções, módulos, pacotes, . ..) para atingir esse objetivo em diferentes níveis.

• O conceito de SRP é baseado na coesão (alta coesão), enquanto o SoC está próximo de Molecularidade, dividir e conquistar (D&C), ...em cada nível de abstração.

• SoC é um bom princípio de design para lidar com complexidade, como abstração, enquanto para alcançar classes únicas responsáveis ​​você pode usar o princípio SoC como uma ótima solução.Pois, uma forma de saber que uma classe tem mais de uma responsabilidade é se você puder extrair outra responsabilidade (preocupação) dessa classe.

Semelhanças

• Depois de aplicar cada um desses princípios, seu contexto se torna mais reutilizável, sustentável, robusto, legível,....

Answer 12

Responda:

Separação de preocupações (SOC) é um termo mais versátil - ele pode ser aplicado no nível do sistema ou em níveis mais baixos, como classes (ou mesmo os métodos dentro de uma classe)

Princípio de responsabilidade única (SRP) é usado para discutir o SOC nos níveis mais baixos, por exemplo, em uma classe

---

Maneiras de pensar sobre isso:

1. No nível baixo, o SOC e o SRP são sinônimos. Então você poderia dizer que o SRP é um termo redundante - ou que o SOC só deve ser usado para discutir o nível do sistema

2. Dado (1), o termo SOC é um tanto ambíguo. Você precisa de contexto para saber se a discussão é sobre SoC de alto nível ou SoC de nível inferior

3. Lembre-se de que o SRP é o termo apenas para níveis mais baixos, pense nisso: na linguagem cotidiana, uma "responsabilidade" geralmente é uma coisa bem definida que pode estar ligada a um código específico, enquanto que "preocupações" são geralmente meio vagas e podem englobar um monte de coisas relacionadas, e talvez por isso que o SOC é mais natural para discutir o nível do sistema do que o SRP

4. SOC é, em certo sentido, um mais forte requisito/princípio que o SRP porque se aplica ao nível do sistema e para ser realmente alcançado no nível do sistema também deve ser usado no desenvolvimento dos componentes do sistema. Isto é, um alto nível de SOC implica SOC/SRP decente nos níveis mais baixos - mas o inverso não é verdadeiro, ou seja, o SOC/SRP de nível inferior não implica o SOC ou qualquer coisa para o próximo nível superior, não importa o sistema abrangente. Para um exemplo de SOC/SRP que é alcançado no nível do método, mas depois violado no nível da aula, confira isso Postagem do blog de Artur Trosin.