Princípio da Responsabilidade Única (SRP) não leva em consideração a coesão?

Opa Acaz, blz cara. Vai aparecer gente te detonando sim, mas não liga isso é em todo lugar… rsrsrsrsrsrs, tenta focar em quem vai manter uma discussão sadia contigo e esses vão aparecer por aqui.

Então vamos lá.

Eu estando tentando entender, porque separar as responsabilidades em classe diminui a coesão conforme você afirmou ??? Coesão no conceito de Arquitetura e Design de Software nada mais é do que manter um Objeto com um mínimo de responsabilidade.

No momento em que você divide um objeto que tem 2 responsabilidades distintas em 2 objetos, cada um com uma única responsabilidade, você diminui ou aumenta a coesão ???

Não sei se entendi errado sua questão.

Abs []

O padrão Estrategy aborda essa problemática de coesão. A questão “que uma classe dever ter apenas uma razão para mudar” está meio confusa. Mudar de responsabilidade? Se for, a lógica me parece furada. Veja um exemplo; a classe Programador tem somente uma responsabilidade :lol: , um método que é programar(), porém, o cliente quer que além de programar ele também faça a analise, portanto, aparentemente, essa classe já teria tem duas razões para mudar. A primeira é pq é programador e a segunda é pq deve analisar??
:lol: :lol: :lol: :lol:

O SRP diz que você só deveria alterar uma classe se alguma regra ou característica referente ao que a classe se propõe a fazer também mudar. Por exemplo, se mudou uma regra na validação de cliente, esta regra não deveria resultar em manutenção de código em classes de Fornecedor, ou Produto, ou qualquer outra coisa que não seja Cliente. Implicitamente, a coesão está correlacionada, porque se a classe possui alta coesão, ela tem propósitos claros e definidos, não misturando diferentes assuntos em uma classe.

Olá,

Princípio da Responsabilidade Única tem tudo a ver com Coesão!

Acho que o motivo dessa confusão é que você está entendendo Responsabilidade Única com “Operação Única”.

Uma classe deve ter apenas uma responsabilidade, mas isso não quer dizer que só possa ter uma operação. Ele deve ter todas as operações que são necessárias para o cumprimento dessa responsabilidade - aí é que entra a coesão.

Por outro lado, o que sempre vai causar discussão é: Até onde vai a responsabilidade de um objeto?
Mas independente do resultado dessa pergunta, a coesão e o princípio da responsabilidade única andam juntos.

Vamos ver seu exemplo:
Considerando que o Sort é uma responsabilidade da própria lista, então ele deverá ser uma operação do próprio objeto, de forma a manter a coesão.
Se por outro lado, considerarmos que Sort não é responsabilidade da lista, então ele deveria ficar separado em um ListSorter.

Não sei se expliquei bem… deu para perceber que os dois princípios acabam concordando um com o outro?

PS: Eu não gostei dessa forma de definir: “a classe deve ter apenas uma razão para mudar”. Isso leva a uma confusão de conceitos.

Assim melhora bastante.
“a classe deve ter apenas uma razão para mudar” leva a entender que não é possível ter vários métodos, e que eventualmente eles possam sofrer alterações isoladas.

Desse jeito que você colocou fica consistente.

“Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change.”

Realmente essa citação é o que está me confundindo, porque se for olhar uma Lista tem várias razões para mudar: ela faz Sort, reverse, Find, etc.

Concordo com o adriano_si, ao diminuir a responsabilidade a classe passa a ter maior coesão. Quanto a questão da razão para mudar significa que, se houver mudanças, você irá atuar numa classe cujo comportamento controle exclusivamente esse comportamento. A responsabilidade se mantém, porém como a mesma se comporta pode mudar.

Neste site há um exemplo que ilustra a questão de coesão: http://www.macoratti.net/08/06/net_srp1.htm

E aqui, uma explicação sobre a questão da “razão para mudar”: http://msdn.microsoft.com/pt-br/magazine/cc546578.aspx#id0390008

gomesrod:

PS: Eu não gostei dessa forma de definir: “a classe deve ter apenas uma razão para mudar”. Isso leva a uma confusão de conceitos.

acazsouza:

“Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change.”

Realmente essa citação é o que está me confundindo, porque se for olhar uma Lista tem várias razões para mudar: ela faz Sort, reverse, Find, etc.