O SRP (princípio de responsabilidade única) é objetivo?

Considere dois designers de interface do usuário que desejam criar designs "atraentes para o usuário". "Atração do usuário" é um conceito que não é objetivo e reside apenas na mente dos designers. Assim, o designer A pode, por exemplo, escolher a cor vermelha, enquanto o designer B escolhe o azul. Designer A cria um layout totalmente diferente do designer B e assim por diante.

Li sobre SRP (princípio de responsabilidade única) e o que entendi foi uma espécie de análise subjetiva ou quebra de responsabilidades que podem variar de um designer de OO para outro designer de OO. Estou certo? Em outras palavras, é possível ter dois excelentes analisadores e designers orientados a objetos que criam dois projetos diferentes para um sistema baseado no principal SRP?

Uma boa pergunta e uma que eu costumava ponderar.

Eu diria que não é objetivo, não. Definitivamente subjetivo. A maneira como você aborda a quebra de problemas depende de sua filosofia para esse tipo de problema. A ciência nos mostra que pode haver muitas maneiras diferentes de resolver o mesmo problema efetivamente. A ciência também mostra que pessoas distantes dos continentes podem apresentar as mesmas soluções de forma independente e, portanto, algumas soluções são mais óbvias que outras. De qualquer forma, julgar as soluções em termos de "melhor" depende dos seus critérios.

Realmente, o que alguém pode ver como duas partes do mesmo todo, outro pode ver como dois conceitos totalmente separados. Vê-se isso o tempo todo ao analisar como os mantenedores de diferentes bibliotecas de código abordam o mesmo problema. E, no entanto, ambas as soluções funcionam bem.

(PS. Editou esta resposta porque a pergunta final do OP pergunta o oposto do título da pergunta.)

O princípio em si é objetivo, mas há tantas maneiras diferentes de implementar algo que segue o princípio, que dois desenvolvedores independentes quase sempre apresentam projetos de sistemas bastante diferentes para o mesmo aplicativo.

É provável que o mesmo desenvolvedor que faça o mesmo design duas vezes ainda tenha duas soluções que diferem pelo menos parcialmente.

Para que um princípio faça com que os projetos do sistema sempre tenham a mesma aparência, ele deverá cobrir todos os aspectos das decisões de projeto. O diretor de responsabilidade única cobre apenas uma pequena parte das decisões de projeto envolvidas na criação de qualquer projeto de sistema.

A aplicação do princípio é subjetiva. No entanto, "subjetivo" não equivale a "preferência" da mesma maneira que a estética.

Existem extremos óbvios. Uma classe com exatamente um método, com apenas algumas linhas de código, que não chama nenhuma outra classe, está definitivamente seguindo o SRP. Por outro lado, uma classe com dois métodos, um que contém uma implementação completa de email por soquetes brutos e outro que cria um formulário da GUI, definitivamente não está seguindo o SRP.

A estética é uma analogia ruim. Uma analogia melhor seria os conceitos bem conhecidos da ciência da computação de acoplamento e coesão . Nenhum desses atributos é preto ou branco, verdadeiro ou falso. No entanto, eles são mensuráveis, mesmo se houver um elemento qualitativo. Se você mostrar a um grupo de desenvolvedores experientes dois designs separados para o mesmo recurso, eles fornecerão leituras semelhantes nas quais o design tem mais acoplamento e / ou coesão.

De fato, o SRP é essencialmente apenas coesão funcional. Ele diz que as partes de algum módulo (por exemplo, classe) devem ser agrupadas porque todas elas contribuem para a execução da mesma função e por nenhum outro motivo. "Função" pode estar sujeita a interpretação - algumas pessoas podem interpretar isso literalmente como uma única declaração de função (ou método ou procedimento) , outras podem recuar um pouco e pensar em uma função como "enviando email" ou "tocando música" , mas ainda há muito espaço para manobrar. "Gerenciando coisas" não é uma descrição funcional válida.

Há uma definição objetiva da "responsabilidade" como uma "razão para mudar". No momento da programação, todos os motivos para mudar estão no futuro; portanto, o programador pode adivinhar com base em sua experiência e conhecimento de domínio. Portanto, analisar as responsabilidades é uma espécie de previsão, em parte subjetiva.

SRP é objetivo; implementações são subjetivas

duas implementações com a mesma funcionalidade exata podem usar estruturas internas completamente diferentes, o que resulta em diferentes classes e métodos, e ambas podem satisfazer o SRP

se eles usarem os mesmos métodos e estado, e ambos forem normalizados (mínimo / não redundante), eles irão, em teoria, acabar com as mesmas classes e métodos no SRP.

mas não posso provar isso. Ainda.