A responsabilidade única pode não ser algo que uma única função possa cumprir.
class Location {
public int getX() {
return x;
}
public int getY() {
return y;
}
}
Esta classe pode violar o princípio da responsabilidade única. Não porque tem duas funções, mas se o código getX()e getY()precisa satisfazer diferentes partes interessadas que podem exigir mudanças. Se o vice-presidente Sr. X enviar um memorando de que todos os números serão expressos como números de ponto flutuante e a diretora de contabilidade, a Sra. Y, insistir em que todos os números que suas revisões de departamento permanecerão inteiros, independentemente do que o Sr. X pense bem, então é melhor que essa classe tenha uma única idéia de quem é responsável, porque as coisas estão prestes a ficar confusas.
Se o SRP tivesse sido seguido, seria claro se a classe Location contribui para as coisas às quais o Sr. X e seu grupo estão expostos. Deixe claro o que a classe é responsável e você sabe qual diretiva afeta essa classe. Se ambos impactam essa classe, ela foi mal projetada para minimizar o impacto da mudança. "Uma turma deve ter apenas um motivo para mudar" não significa que toda a turma possa fazer apenas uma coisinha. Isso significa que eu não deveria poder olhar para a classe e dizer que o Sr. X e a Sra. Y têm interesse nessa classe.
Além de coisas assim. Não, vários métodos estão bem. Apenas dê um nome que deixe claro quais métodos pertencem à classe e quais não.
O SRP do tio Bob é mais sobre a lei de Conway do que sobre a lei de Curly . O tio Bob defende a aplicação da lei de Curly (faça uma coisa) a funções e não a classes. O SRP adverte contra os motivos de mistura para alterar juntos. A lei de Conway diz que o sistema seguirá como as informações de uma organização fluem. Isso leva a seguir o SRP porque você não se importa com o que nunca ouve.
"Um módulo deve ser responsável por um e apenas um ator"
Robert C Martin - Arquitetura Limpa
As pessoas continuam querendo que o SRP tenha todos os motivos para limitar o escopo. Há mais motivos para limitar o escopo do que o SRP. Limito ainda mais o escopo, insistindo que a classe seja uma abstração que pode ter um nome que garante que olhar para dentro não o surpreenda .
Você pode aplicar a Lei de Curly às aulas. Você está fora do que o tio Bob fala, mas pode fazê-lo. O erro é quando você começa a pensar que isso significa uma função. É como pensar que uma família deveria ter apenas um filho. Ter mais de um filho não impede que seja uma família.
Se você aplicar a lei de Curly a uma classe, tudo na classe deve ser sobre uma única idéia unificadora. Essa ideia pode ser ampla. A ideia pode ser persistência. Se algumas funções do utilitário de registro estiverem lá, elas estarão claramente fora do lugar. Não importa se o Sr. X é o único que se importa com esse código.
O princípio clássico a ser aplicado aqui é chamado de Separação de Preocupações . Se você separar todas as suas preocupações, pode-se argumentar que o que resta em qualquer lugar é uma preocupação. Foi assim que chamamos essa idéia antes do filme de 1991, City Slickers, que nos apresentou o personagem Curly.
Isto é bom. Só que o que o tio Bob chama de responsabilidade não é uma preocupação. Uma responsabilidade para ele não é algo em que você se concentra. É algo que pode forçá-lo a mudar. Você pode se concentrar em uma preocupação e ainda criar um código responsável por diferentes grupos de pessoas com diferentes agendas.
Talvez você não se importe com isso. Bem. Pensar que segurar para "fazer uma coisa" resolverá todos os problemas de seu design mostra uma falta de imaginação do que "uma coisa" pode acabar sendo. Outro motivo para limitar o escopo é a organização. Você pode aninhar muitas "uma coisa" dentro de outras "uma coisa" até ter uma gaveta de lixo cheia de tudo. Eu já falei sobre isso antes
É claro que o motivo clássico da OOP para limitar o escopo é que a classe possui campos particulares e, em vez de usar getters para compartilhar esses dados, colocamos todos os métodos que precisam desses dados na classe, onde eles podem usar os dados em particular. Muitos acham isso muito restritivo para usar como um limitador de escopo, porque nem todo método que pertence junto usa exatamente os mesmos campos. Eu gosto de garantir que qualquer ideia que reuniu os dados seja a mesma que reuniu os métodos.
A maneira funcional de analisar isso é isso a.f(x)e a.g(x)são simplesmente f a (x) e g a (x). Não são duas funções, mas um continuum de pares de funções que variam juntas. O amesmo não tem de ter dados nela. Pode ser simplesmente como você sabe qual fe gimplementação você usará. Funções que mudam juntas pertencem juntas. Esse é o bom e velho polimorfismo.
O SRP é apenas uma das muitas razões para limitar o escopo. É um bom. Mas não é o único.