SRP (Single Responsibility Principle) è obiettivo?

Prendi in considerazione due progettisti dell'interfaccia utente che desiderano progettare progetti "attraenti per l'utente". "Attrazione dell'utente" è un concetto che non è oggettivo e risiede solo nella mente dei progettisti. Così il designer A potrebbe ad esempio prendere il colore rosso, mentre il designer B sceglie il blu. Il designer A crea un layout che è completamente diverso dal designer B e così via.

Ho letto di SRP (Single Responsibility Principle) e quello che ho capito era una specie di analisi soggettiva o suddivisione delle responsabilità che possono variare da un progettista OO a un altro progettista OO. Ho ragione? In altre parole, è possibile avere due eccellenti analizzatori e designer orientati agli oggetti che escogitano due diversi design per un sistema basato sul principio SRP?

Una buona domanda e una a cui ero solito rimuginare.

Direi non oggettivo, no. Decisamente soggettivo. Il modo in cui affrontate la scomposizione dei problemi dipende dalla vostra 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 a parte i continenti possono trovare le stesse soluzioni in modo indipendente, 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 uno potrebbe vedere come due parti dello stesso insieme, un altro potrebbe vedere come due concetti totalmente separati. Lo si vede sempre osservando come i manutentori di diverse librerie di codici affrontano lo stesso problema. Eppure entrambe le soluzioni funzionano bene.

(PS. Modificato questa risposta in quanto l'ultima domanda del PO pone l'opposto del titolo della domanda.)

Il principio in sé è oggettivo, ma ci sono così tanti modi diversi di implementare qualcosa che segue il principio, che due sviluppatori indipendenti quasi sempre realizzeranno progetti di sistema piuttosto diversi per la stessa applicazione.

È anche probabile che lo stesso sviluppatore che faccia lo stesso design due volte, continuerà a proporre due soluzioni che differiscono almeno in parte.

Affinché un principio faccia in modo che i progetti di sistema abbiano sempre lo stesso aspetto, dovrebbe coprire ogni aspetto delle decisioni di progettazione. Il principale responsabile unico copre solo una piccola parte delle decisioni di progettazione coinvolte nella realizzazione di qualsiasi progettazione di sistema.

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

Ci sono estremi ovvi. Una classe con esattamente un metodo, con solo poche righe di codice, che non chiama altre classi, sta sicuramente seguendo l'SRP. D'altra parte, una classe con due metodi, uno che contiene un'implementazione di posta elettronica completa tramite socket non elaborati e un altro che crea un modulo GUI, sicuramente non segue l'SRP.

L'estetica è una scarsa analogia. Una migliore analogia sarebbero i noti concetti informatici di accoppiamento e coesione . Nessuno di questi sono attributi in bianco e nero, vero o falso. Tuttavia, sono misurabili, anche se c'è un elemento qualitativo. Se mostri a un gruppo di sviluppatori esperti due progetti separati per la stessa funzione, forniranno letture simili su quale progetto ha più accoppiamento e / o coesione.

In effetti, l'SRP è essenzialmente solo coesione funzionale. Dice che le parti di alcuni moduli (ad es. Classe) dovrebbero essere raggruppate perché contribuiscono tutte a svolgere la stessa funzione e per nessun altro motivo. La "funzione" può essere soggetta a interpretazione - alcune persone possono interpretarla letteralmente come una singola dichiarazione di funzione (o metodo o procedura) , altre possono fare un passo indietro e pensare a una funzione come "invio di e-mail" o "riproduzione di musica" , ma c'è ancora così tanto spazio da manovrare. "Gestione delle cose" non è una descrizione funzionale valida.

Esiste una definizione obiettiva della "responsabilità" come "motivo per cambiare". Al momento della programmazione tutti i motivi per cambiare risiedono in 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 è obiettivo; 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), in teoria finiranno con le stesse classi e metodi sotto SRP.

ma non posso provarlo. Ancora.