L'obiettivo SRP (principio di responsabilità singola) è?

Una buona domanda e una che rimuginavo spesso.

Direi non obiettivo, no. Sicuramente soggettivo. Il modo in cui ti avvicini alla suddivisione dei problemi dipende dalla tua filosofia verso quel tipo di problema. La scienza ci mostra che ci possono essere molti modi diversi per risolvere efficacemente lo stesso problema. La scienza ci mostra anche che le persone in disparte possono trovare le stesse soluzioni indipendentemente, e quindi alcune soluzioni sono più ovvie di altre. In ogni caso, giudicare le soluzioni in termini di "migliore" dipende dai tuoi criteri.

In realtà, ciò che si potrebbe vedere come due parti dello stesso insieme, un altro potrebbe vedere come due concetti completamente separati. Si vede tutto questo tempo quando si guarda a come i manutentori delle diverse librerie di codice si avvicinano allo stesso problema. Eppure entrambe le soluzioni funzionano bene.

(PS. Modificata questa risposta come domanda finale dell'OP chiede l'opposto del titolo della domanda.)

Il principio stesso è oggettivo, ma ci sono così tanti modi diversi di implementare qualcosa che segue il principio, che due sviluppatori indipendenti creeranno quasi sempre design di sistemi piuttosto diversi per la stessa applicazione.

È anche probabile che lo stesso sviluppatore esegua due volte lo stesso progetto, ma creerà ancora due soluzioni che differiscono almeno parzialmente.

Affinché un principio faccia apparire sempre lo stesso il design del sistema, dovrebbe coprire ogni aspetto delle decisioni di progettazione. Il principio di responsabilità unica copre solo una piccola parte delle decisioni progettuali coinvolte nella realizzazione di qualsiasi progetto di sistema.

L'applicazione del principio è soggettiva. Tuttavia, "soggettivo" non equivale a "preferenza" allo stesso modo dell'estetica.

Ci sono degli estremi ovvi. Una classe con un solo metodo, con solo poche righe di codice, che non richiama altre classi, è sicuramente che segue l'SRP. D'altra parte, una classe con due metodi, uno che contiene un'implementazione completa tramite e-mail tramite socket raw e l'altro che crea un modulo per la GUI, è sicuramente not che segue l'SRP.

L'estetica è una scarsa analogia. Un'analogia migliore sarebbero i ben noti concetti di informatica di accoppiamento e cohesion . Nessuno di questi sono attributi in bianco e nero, veri o falsi. Tuttavia, sono misurabili, anche se esiste un elemento qualitativo. Se mostri a un gruppo di sviluppatori esperti due design separati per la stessa funzione, forniranno letture simili su quale design ha più accoppiamento e / o coesione.

In realtà, l'SRP è essenzialmente solo una coesione funzionale. Dice che le parti di alcuni moduli (ad es. Classe) dovrebbero essere raggruppate perché tutte contribuiscono a svolgere la stessa funzione e per nessun altro motivo. La "funzione" può essere soggetta a interpretazione - alcune persone possono interpretarlo letteralmente come una singola funzione (o metodo o procedura) dichiarazione , altri possono fare un passo indietro e pensare a una funzione come "invio di e- mail "o" riproduzione musicale ", ma c'è ancora molto spazio di manovra. "Gestire le cose" non è una descrizione funzionale valida.

Esiste una definizione oggettiva della "responsabilità" come "motivo per cambiare". Nel tempo della programmazione tutti i motivi per cambiare si trovano nel futuro, quindi il programmatore può solo indovinare in base alla sua esperienza e conoscenza del dominio. Quindi analizzare le responsabilità è una sorta di previsione, in parte soggettiva.

SRP è oggettivo; le implementazioni sono soggettive

due implementazioni con la stessa identica funzionalità possono utilizzare strutture interne completamente diverse, il che si traduce in classi e metodi diversi, ed entrambi possono soddisfare SRP

se usano gli stessi metodi e lo stesso stato, ed entrambi sono normalizzati (minimi / non ridondanti), allora - in teoria - finiranno con le stesse classi e metodi sotto SRP.

ma non posso provarlo. Yet.